Monitoring as Code.
Or just ask your agent.

Write your API monitors, alerts and status pages as YAML or JavaScript, keep them in Git, and deploy them from CI. Don't want to write config? Connect an MCP client and set them up in plain English.

$ npx @loadfocus/monitoring init copy Start free →Connect 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.

Works inside your stack

CODE-FIRST

Your monitors live next to your code

No clicking through dashboards. Declare checks, assertions and alerts in plain YAML or typed JavaScript. Review them in pull requests. Deploy them on merge.

✓

Git is the source of truth

Every monitor is versioned, reviewable and reproducible across environments.

↻

Safe plan & apply

A server-computed plan shows exactly what will be created, updated or deleted, with guarded orphan-deletes.

{ }

YAML or JavaScript

Pick declarative configs or typed constructs. Same engine, same result.

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 }
const { Monitor } = require('@loadfocus/monitoring');

module.exports = new Monitor({
  type: 'api',
  logicalId: 'checkout-api',
  name: 'Checkout API',
  schedule: '60',
  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

One CLI for the whole lifecycle

The same six commands work on your machine and in CI. @loadfocus/monitoring is on npm under Apache-2.0.

lf init

Scaffold a project with config and a sample monitor.

lf validate

Compile locally + server dry-run before anything ships.

lf test

Run checks ad-hoc with no persistence, exit code drives CI.

lf deploy

Reconcile state: create, update, delete. --dry-run to preview.

lf trigger

Run already-deployed checks on demand, e.g. after a release.

lf destroy

Tear down resources cleanly. Guarded behind --yes in CI.

Already running monitors in the LoadFocus app? import generates YAML from your live setup, so you can adopt code without rebuilding anything.

Built for CI. Destructive changes exit with a confirmation-required code instead of hanging on a prompt, so you don't get accidental deletes or stuck pipelines.

◆Claudemcp.loadfocus.com

Create a monitor for our checkout API in US + EU, alert me on Slack if p95 goes over 800ms.

Claude · via LoadFocus MCP

On it, creating the monitor and wiring the alert now.

✓ create_api_monitor checkout-api · us-east-1, eu-west-1

✓ create_api_alert responseTime > 800ms → Slack

✓ run_api_monitor 200 OK · 412ms

Done. Checkout API is live in 2 regions and I’ve set a p95 alert to #ops. First check passed at 412ms.

MCP SERVER

Or skip the config, just ask your agent

LoadFocus runs a Model Context Protocol server at mcp.loadfocus.com. Point Claude, Cursor or any MCP client at it and create, run and check monitors by asking. Nothing to install beyond the connection.

40 toolsAPI monitoring

k6 · JMeterLoad testing

LighthousePage speed

OAuthSecure connect

CI/CD NATIVE

Monitoring in your deploy pipeline

Test checks against staging on every PR, then deploy them to production when you merge. Monitoring changes ship with the code that needs them.

▶

GitHub Actions & GitLab CI

Copy-paste workflows ship in the repo. Set two secrets and go.

↯

Test → deploy → trigger

Validate on PR, apply on merge, smoke-test the new release, all from 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

Eight resource kinds, one workflow

Checks are only the start. Groups, alerts, dashboards and status pages are declarative too.

Checks

API, browser, multistep, TCP and heartbeat monitors.

Groups

Shared locations, channels and mute or activate.

Alert rules

Threshold alerts on time, status and duration.

Maintenance

Suppress alerts on a recurring schedule.

Dashboards

Uptime, p95 and sparkline status tiles.

Status pages

Public, branded, on your own domain.

Alert channels

Email, Slack, Teams, webhook, Discord, PagerDuty, Opsgenie.

Variables

Secrets and runtime vars, referenced inline.

HOW WE COMPARE

LoadFocus vs Checkly

The same code-first workflow, plus a live MCP server and an open-source CLI.

	LoadFocus	Checkly
Monitors as code (YAML / JS)	✓ Both	✓ TS
Native MCP server for AI agents	✓ 40 tools, live	× Skills only
Open-source CLI	✓ Apache-2.0	Partial
Load testing (k6 / JMeter)	✓	×
Status pages as code	✓	✓
CI/CD workflows included	✓ GH + GitLab	✓

FAQ

Monitoring as Code, answered

Q.What is monitoring as code?

Defining your monitors, alerts and status pages in version-controlled files instead of clicking through a UI, so they are reviewable, reproducible and deployable through CI/CD.

Q.Do I need to know TypeScript?

No. Use declarative YAML for the simplest path, or typed JavaScript constructs if you prefer code. Both compile to the same resources.

Q.How is this different from Checkly?

Same code-first paradigm, plus a live MCP server so AI agents create monitors conversationally, an Apache-2.0 CLI, and load testing on the same platform.

Q.How do AI agents connect?

Point any MCP client at mcp.loadfocus.com, authenticate via OAuth, and 40 tools become available instantly.

Q.Is it safe to run in CI?

Yes. Deploys compute a plan first, guard orphan-deletes, and exit with a confirmation code instead of hanging on prompts.

Q.What can I manage as code?

Checks (API, browser, multistep, TCP, heartbeat), groups, alert rules, maintenance windows, dashboards, status pages, alert channels and variables.

Set up your monitoring in an afternoon

Install the CLI or connect an MCP client. Your first monitor can be running in minutes.

$ npx @loadfocus/monitoring init copy Start free →

npm · GitHub · Docs · Apache-2.0