Reusable monitoring-as-code baseline using Checkly CLI. Copy into your project, customize for your endpoints, and start monitoring.

See docs/adoption-guide.md for step-by-step adoption instructions.

1. Install dependencies:

   cd checkly
   npm install

2. Configure environment:

   cp .env.example .env
   # Edit .env with your Checkly credentials and target URL

3. Login to Checkly (first time only):

   npm run checkly:login

4. Test checks locally:

   npx checkly test -e ENVIRONMENT_URL=https://your-site.com --verbose

5. Preview deployment:

   npx checkly deploy --preview

checkly-baseline/
├── .github/workflows/checkly.yml        # GitHub Actions CI/CD
├── ci-cd/azure-pipelines/
│   ├── checkly-standalone.yml           # Standalone pipeline (manual/scheduled)
│   └── templates/
│       └── checkly-job.yml              # Pipeline template (post-deploy stage)
├── __checks__/
│   ├── monitoring/                      # Always-on checks (deployed, run 24/7)
│   │   ├── url-monitors.check.ts        # URL monitors
│   │   └── heartbeat.check.ts           # Heartbeat monitor (deactivated)
│   ├── deployment/                      # On-demand checks (run after release)
│   │   ├── api-health.check.ts          # API health check
│   │   ├── browser-homepage.check.ts    # Browser check (deactivated)
│   │   └── browser-homepage.spec.ts     # Playwright spec for browser check
│   └── utils/
│       ├── alert-channels.ts            # Email alert channel
│       ├── check-groups.check.ts        # Monitoring + Deployment groups
│       └── setup.ts                     # Auth setup script stub
├── checkly.config.ts                    # Checkly project configuration
├── playwright.config.ts                 # Playwright configuration
├── package.json
├── .env.example
└── .gitignore

Configured in __checks__/utils/alert-channels.ts. By default, only email alerts are active. Slack and Webhook channel stubs are included as comments.

Configured in __checks__/utils/check-groups.check.ts:

• Monitoring (always-on) — activated: true, 5min frequency, tagged monitoring. Deployed to Checkly cloud and runs on schedule 24/7.
• Deployment validation (on-demand) — activated: false, tagged deployment. Only runs via CLI after a release.

EU-only by default: eu-central-1, eu-west-1. Change in checkly.config.ts and check-groups.check.ts.

Place in __checks__/monitoring/. These are deployed to Checkly and run continuously.

import { UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
import { monitoringGroup } from '../utils/check-groups.check'

new UrlMonitor('my-url-monitor', {
  name: 'My URL Monitor',
  group: monitoringGroup,
  request: {
    url: '{{ENVIRONMENT_URL}}/my-page',
    assertions: [ UrlAssertionBuilder.statusCode().equals(200) ],
  },
})

Place in __checks__/deployment/. These run via CLI after a release to validate the deployment.

import { ApiCheck, AssertionBuilder } from 'checkly/constructs'
import { deploymentGroup } from '../utils/check-groups.check'

new ApiCheck('my-api-check', {
  name: 'My API Check',
  group: deploymentGroup,
  request: {
    url: '{{ENVIRONMENT_URL}}/api/endpoint',
    method: 'GET',
    assertions: [
      AssertionBuilder.statusCode().equals(200),
    ],
  },
})

Create a *.check.ts and corresponding *.spec.ts file. Place in the directory matching the check's purpose:

// my-flow.check.ts
import * as path from 'path'
import { BrowserCheck } from 'checkly/constructs'
import { deploymentGroup } from '../utils/check-groups.check'

new BrowserCheck('my-flow-check', {
  name: 'My Flow Check',
  group: deploymentGroup,  // or monitoringGroup
  code: { entrypoint: path.join(__dirname, 'my-flow.spec.ts') },
})

Edit __checks__/monitoring/heartbeat.check.ts and set activated: true after configuring your ping endpoint.

Each environment (production, staging, etc.) deploys as a separate Checkly project with its own logicalId, controlled by the CHECKLY_ENVIRONMENT variable. Environment-specific configuration lives in .env.{environment} files which override values from .env.

1. .env is loaded first (shared credentials, production defaults)
2. .env.{environment} is loaded on top with override (e.g. .env.staging sets ENVIRONMENT_URL)
3. All Checkly constructs get an environment-suffixed logicalId to avoid conflicts

1. Copy .env.staging.example to .env.{name} (e.g. .env.staging)
2. Set the ENVIRONMENT_URL and any other overrides
3. Run with cross-env CHECKLY_ENVIRONMENT={name} or set the env var directly

# Test staging
cross-env CHECKLY_ENVIRONMENT=staging npx checkly test --verbose

# Deploy staging
cross-env CHECKLY_ENVIRONMENT=staging npx checkly deploy --force

# Destroy staging
cross-env CHECKLY_ENVIRONMENT=staging npx checkly destroy

In pipelines, set environment: Staging — the pipeline passes this as CHECKLY_ENVIRONMENT to all steps.

Choose the integration pattern that fits your deployment process. All options require a variable group / secrets containing CHECKLY_API_KEY and CHECKLY_ACCOUNT_ID.

Best when deployments are handled by a separate team or process and you can't hook into the deploy pipeline directly. The pipeline can be triggered manually from the Azure DevOps UI or run on a schedule.

Use ci-cd/azure-pipelines/checkly-standalone.yml as a pipeline definition:

# Trigger manually from Azure DevOps UI with these parameters:
#   - environment: Production
#   - environmentUrl: https://www.example.com
#   - deployChecks: true/false

# Or uncomment the schedules section in the file to run periodically

Best when your build pipeline also deploys to the target environment. Add Checkly as a stage after deployment completes.

Use ci-cd/azure-pipelines/templates/checkly-job.yml as a job template:

stages:
  - stage: ChecklyMonitoring
    dependsOn: Deploy
    jobs:
      - template: checkly/ci-cd/azure-pipelines/templates/checkly-job.yml
        parameters:
          environment: 'Production'
          environmentUrl: 'https://www.example.com'
          deployChecks: true

The workflow at .github/workflows/checkly.yml triggers on deployment_status events. Add CHECKLY_API_KEY and CHECKLY_ACCOUNT_ID as repository secrets.

# Run deployment checks only (after a release)
npx checkly test --tags deployment -e ENVIRONMENT_URL=https://your-site.com --verbose

# Run monitoring checks only
npx checkly test --tags monitoring -e ENVIRONMENT_URL=https://your-site.com --verbose

# Run all checks
npx checkly test -e ENVIRONMENT_URL=https://your-site.com --verbose

# Record test results in Checkly
npx checkly test --tags deployment -e ENVIRONMENT_URL=https://your-site.com --record

# Preview what would be deployed
npx checkly deploy --preview

# Deploy checks to Checkly (monitoring checks run 24/7, deployment checks stay deactivated)
npx checkly deploy --force

# Run Playwright specs locally
npx playwright test

# Login to Checkly
npx checkly login

When adopting this baseline for your project, you'll typically need to:

1. Update checkly.config.ts — set projectName and logicalId (marked with TODO comments)
2. Update locations — default is EU-only (eu-central-1, eu-west-1); change in checkly.config.ts and check-groups.check.ts
3. Update checks — adapt API endpoints, browser selectors, and URL paths for your site
4. Activate browser checks — deactivated by default since they need real selectors
5. Configure alerts — set ALERT_EMAIL_ADDRESS in .env, optionally enable Slack/Webhook channels

See docs/adoption-guide.md for the full checklist.