Monitoring as Code.
Ou demandez simplement à votre agent.

Écrivez vos moniteurs API, alertes et pages de statut en YAML ou JavaScript, conservez-les dans Git et déployez-les depuis votre CI. Vous ne voulez pas écrire de config ? Connectez un client MCP et configurez-les en langage clair.

$ npx @loadfocus/monitoring init copier Commencer gratuitement →Se connecter via MCP →
~/acme-monitors - zsh
# define once, deploy everywhere
$ npx @loadfocus/monitoring deploy
  Plan: 4 to create, 1 to update, 0 to delete
   check        checkout-api      created   us-east-1, eu-west-1
   check        login-flow       created   browser · 3 steps
   alertRule    api-p95-slow     created   → Slack #ops
   statusPage   acme-status      created   acme.loadfoc.us
   group        web              updated
  Deployed 5 resources in 2.3s. Monitoring is now live.
S'intègre dans votre stack
ClaudeCursorGitHub ActionsGitLab CISlackPagerDutyOpsgeniePlaywright
CODE-FIRST

Vos moniteurs vivent à côté de votre code

Fini les clics dans les tableaux de bord. Déclarez vos checks, assertions et alertes en YAML clair ou en JavaScript typé. Relisez-les dans vos pull requests. Déployez-les au merge.

Git est la source de vérité

Chaque moniteur est versionné, relisible et reproductible d'un environnement à l'autre.

Plan & apply sécurisés

Un plan calculé côté serveur montre exactement ce qui sera créé, mis à jour ou supprimé, avec des suppressions d'orphelins protégées.

{ }

YAML ou JavaScript

Choisissez des configs déclaratives ou des constructs typés. Même moteur, même résultat.

monitors/checkout-api.check.yaml
YAMLJS
kind: check
type: api
logicalId: checkout-api
name: Checkout API
schedule: "60"            # seconds
locations: [us-east-1, eu-west-1]
request:
  url: https://api.acme.com/checkout
  method: POST
  headers:
    - { key: Authorization, value: "Bearer {{secrets.TOKEN}}" }
assertions:
  - { type: statusCode, comparison: equals, value: 200 }
  - { type: responseTime, comparison: below, value: 800 }

    
THE CLI

Une CLI pour tout le cycle de vie

Les six mêmes commandes fonctionnent sur votre machine et dans votre CI. @loadfocus/monitoring est disponible sur npm sous licence Apache-2.0.

lf init

Génère un projet avec sa config et un moniteur d'exemple.

lf validate

Compile en local + dry-run côté serveur avant tout déploiement.

lf test

Exécute les checks à la demande sans persistance, le code de sortie pilote la CI.

lf deploy

Réconcilie l'état : créer, mettre à jour, supprimer. --dry-run pour prévisualiser.

lf trigger

Lance à la demande des checks déjà déployés, par exemple après une mise en production.

lf destroy

Démantèle les ressources proprement. Protégé par --yes en CI.

Vous avez déjà des moniteurs dans l'app LoadFocus ? import génère du YAML à partir de votre configuration en place, pour adopter le code sans rien refaire.

Conçue pour la CI. Les changements destructifs se terminent avec un code « confirmation requise » plutôt que de bloquer sur une invite, pour éviter les suppressions accidentelles et les pipelines coincés.

Claudemcp.loadfocus.com
Crée un moniteur pour notre API de checkout aux US + EU, et alerte-moi sur Slack si le p95 dépasse 800 ms.
Claude · via LoadFocus MCP
C'est parti, je crée le moniteur et je câble l'alerte tout de suite.
create_api_monitor  checkout-api · us-east-1, eu-west-1
create_api_alert  responseTime > 800ms → Slack
run_api_monitor  200 OK · 412ms
Terminé. Checkout API est en ligne sur 2 régions et j’ai configuré une alerte p95 vers #ops. Le premier check est passé à 412 ms.
MCP SERVER

Ou oubliez la config, demandez simplement à votre agent

LoadFocus exécute un serveur Model Context Protocol à l'adresse mcp.loadfocus.com. Pointez-y Claude, Cursor ou n'importe quel client MCP et créez, lancez et vérifiez vos moniteurs en demandant. Rien à installer au-delà de la connexion.

k6 · JMeterTests de charge
LighthouseVitesse des pages
OAuthConnexion sécurisée
CI/CD NATIVE

Le monitoring dans votre pipeline de déploiement

Testez vos checks contre la staging à chaque PR, puis déployez-les en production au merge. Les changements de monitoring partent avec le code qui en a besoin.

GitHub Actions & GitLab CI

Des workflows prêts à copier-coller sont livrés dans le dépôt. Deux secrets à définir et c'est parti.

Test → deploy → trigger

Validez à la PR, appliquez au merge, smoke-testez la nouvelle release, le tout depuis la CI.

.github/workflows/monitoring.yml
name: monitoring-as-code
on: [push, pull_request]
jobs:
  reconcile:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx @loadfocus/monitoring test
        # dry-run on every PR
      - if: github.ref == 'refs/heads/main'
        run: npx @loadfocus/monitoring deploy --yes
        env:
          LOADFOCUS_API_KEY: ${{ secrets.LF_KEY }}
          LOADFOCUS_TEAM_ID: ${{ secrets.LF_TEAM }}
EVERYTHING AS CODE

Huit types de ressources, un seul workflow

Les checks ne sont qu'un début. Les groupes, alertes, tableaux de bord et pages de statut sont eux aussi déclaratifs.

Checks

Moniteurs API, browser, multistep, TCP et heartbeat.

Groupes

Localisations et canaux partagés, mise en sourdine ou activation.

Règles d'alerte

Alertes de seuil sur le temps, le statut et la durée.

Maintenance

Suppression des alertes sur un calendrier récurrent.

Tableaux de bord

Tuiles de statut : uptime, p95 et sparklines.

Pages de statut

Publiques, personnalisées, sur votre propre domaine.

Canaux d'alerte

E-mail, Slack, Teams, webhook, Discord, PagerDuty, Opsgenie.

Variables

Secrets et variables d'exécution, référencés inline.

HOW WE COMPARE

LoadFocus vs Checkly

Le même workflow code-first, plus un serveur MCP en direct et une CLI open source.

LoadFocusCheckly
Moniteurs as code (YAML / JS)✓ Les deux✓ TS
Serveur MCP natif pour agents IA✓ 40 outils, en direct× Skills seulement
CLI open source✓ Apache-2.0Partiel
Tests de charge (k6 / JMeter)×
Pages de statut as code
Workflows CI/CD inclus✓ GH + GitLab
FAQ

Monitoring as Code, vos questions

Q.Qu'est-ce que le monitoring as code ?

C'est définir vos moniteurs, alertes et pages de statut dans des fichiers versionnés plutôt qu'en cliquant dans une interface, pour qu'ils soient relisibles, reproductibles et déployables via CI/CD.

Q.Dois-je connaître TypeScript ?

Non. Utilisez du YAML déclaratif pour la voie la plus simple, ou des constructs JavaScript typés si vous préférez le code. Les deux compilent vers les mêmes ressources.

Q.En quoi est-ce différent de Checkly ?

Le même paradigme code-first, plus un serveur MCP en direct pour que les agents IA créent des moniteurs en conversation, une CLI Apache-2.0 et des tests de charge sur la même plateforme.

Q.Comment les agents IA se connectent-ils ?

Pointez n'importe quel client MCP vers mcp.loadfocus.com, authentifiez-vous via OAuth, et 40 outils deviennent disponibles instantanément.

Q.Est-ce sûr en CI ?

Oui. Les déploiements calculent d'abord un plan, protègent les suppressions d'orphelins et se terminent avec un code de confirmation plutôt que de bloquer sur des invites.

Q.Que puis-je gérer as code ?

Les checks (API, browser, multistep, TCP, heartbeat), les groupes, les règles d'alerte, les fenêtres de maintenance, les tableaux de bord, les pages de statut, les canaux d'alerte et les variables.

Configurez votre monitoring en une après-midi

Installez la CLI ou connectez un client MCP. Votre premier moniteur peut tourner en quelques minutes.

$ npx @loadfocus/monitoring init copier Commencer gratuitement →
npm · GitHub · Docs · Apache-2.0
×