canonical: https://jentic.com/apis/checklyhq.com/checkly

# Checklyhq Checkly Public API

Jentic publishes the only available OpenAPI specification for Checkly Public API, keeping it validated and agent-ready. Checkly is a synthetic monitoring and reliability platform that runs scheduled API checks, browser checks, and heartbeats from a global network and alerts teams when something breaks. The Public API exposes the building blocks of that platform - checks, check groups, and alert channels - along with on-demand triggers so you can manage monitoring infrastructure as code or from CI/CD pipelines. Most routes share a 600 requests per 60 seconds rate limit.

## For AI agents

Create, update, and trigger Checkly synthetic checks and manage alert channels so an agent can provision uptime monitoring as code.

## Scope

Does not handle log aggregation, application performance monitoring, or incident management - use for managing synthetic checks, check groups, and alert channels only.

## Capabilities

- Create API and browser checks with schedules, locations, and assertions
- Update check definitions to change frequency, alerting, or assertions
- Trigger an ad hoc run of an existing check from CI or an agent
- List checks, check groups, and alert channels for an account
- Delete checks that are no longer needed
- Inspect alert channels (email, Slack, webhook) attached to checks

## Use cases

### Monitoring as Code in CI/CD

Manage Checkly checks from a Git repository alongside application code. A CI job reads the desired state from YAML or JSON files and uses POST `/v1/checks` and PUT `/v1/checks/{id}` to create or update checks on each merge to main. Removed entries trigger DELETE `/v1/checks/{id}.` This keeps monitoring in lockstep with the deployed application.

Example prompt: Create a check named 'login-flow' via POST `/v1/checks` with frequency 5 minutes and locations ['us-east-1','eu-west-1'].

### Post-Deploy Smoke Tests

After every production deployment, trigger a curated set of Checkly checks to confirm the release is healthy. The deploy pipeline calls POST `/v1/checks/{id}/trigger` for each smoke check, waits for the result, and rolls back if any fail. This catches regressions in real network conditions before users notice.

Example prompt: Trigger check id 4242 via POST `/v1/checks/{id}/trigger` and report success or failure.

### Alert Channel Audit

List every alert channel and check group on the account to ensure that every critical service has at least one on-call channel attached. A scheduled job pulls `/v1/checks`, `/v1/check-groups`, and `/v1/alert-channels`, joins them, and flags any check missing an alert channel. Useful for SRE teams maintaining incident response hygiene.

Example prompt: Pull `/v1/checks` and `/v1/alert-channels` and return a list of any check ids that have no alert channels assigned.

### AI Agent for Reliability Operations

An autonomous agent receives an incident alert, identifies the affected check from `/v1/checks`, triggers a manual run via POST `/v1/checks/{id}/trigger`, and reports the result back into the on-call channel - all through Jentic without holding the bearer token in its prompt.

Example prompt: Through Jentic, search 'trigger a check run', load the schema for `/v1/checks/{id}/trigger`, and execute with id 4242.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/checks` | Create a check |
| GET | `/v1/checks` | List all checks |
| GET | `/v1/checks/{id}` | Get a check by ID |
| PUT | `/v1/checks/{id}` | Update a check |
| DELETE | `/v1/checks/{id}` | Delete a check |
| POST | `/v1/checks/{id}/trigger` | Trigger a check run |
| GET | `/v1/check-groups` | List check groups |
| GET | `/v1/alert-channels` | List alert channels |

## Key resources

- **Checks** — Create, list, fetch, update, delete, and trigger synthetic checks
- **Check Groups** — List groups that bundle related checks together
- **Alert Channels** — List email, Slack, and webhook channels used for alerting

## Why Jentic

- **Setup:** Wiring Checkly by hand means handling its bearer key plus the X-Checkly-Account header and finding the right call for checks, groups, and alert channels. Through Jentic you install once, import the Checkly Public API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Checkly puts the check id in the URL path (`/v1/checks/{id}`), so a rule can pin your agent to one check: it can read and trigger that check and nothing else. You choose the operations it may call, so deleting a check is not included unless you add it.
- **Credential handling:** Your Checkly bearer key and account id are stored once, encrypted, by your own Jentic One instance and injected into both headers at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'trigger a check run' or 'create a synthetic check', and Jentic returns the matching Checkly operation with its input schema so the agent picks the right endpoint among 8 without browsing the reference docs.

## Related APIs

- **CheckMob API** — Field workforce check-in monitoring - different domain (people, not synthetic checks)
- **CheetahO API** — Image optimisation API you might monitor with Checkly
- **Chatwoot** — Customer support platform; pair with Checkly to monitor self-hosted Chatwoot uptime

## FAQ

### Why is there no official OpenAPI spec for Checkly Public API?

Checkly publishes API documentation but not a maintained OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Checkly Public API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Checkly Public API use?

Checkly uses HTTP bearer authentication. Each request must include an Authorization header with a bearer API key and an X-Checkly-Account header for the target account id. Through Jentic, both values are stored encrypted in your Jentic One instance and injected at execution time, so the agent never sees the raw key.

### Can I trigger a check run with the Checkly API?

Yes. POST `/v1/checks/{id}/trigger` starts an ad hoc run of an existing check. This is useful for post-deploy smoke testing or for triaging an incident - you do not have to wait for the next scheduled tick.

### How do I create a check via the Checkly API?

Use POST `/v1/checks` with the check name, type, frequency, locations, and request or browser script. The endpoint returns the created check id, which you can then trigger or update.

### What are the rate limits for the Checkly Public API?

Most routes are limited to 600 requests per 60 seconds, as documented in the API description. Plan for retry-with-backoff on 429 responses, especially when bulk-managing checks from CI.

### How do I trigger a Checkly check through Jentic?

Install the SDK with `pip install jentic`, then call Jentic.search('trigger a check run'), load the schema for `/v1/checks/{id}/trigger`, and execute with the check id. Jentic injects the bearer token and X-Checkly-Account header from your Jentic One instance.

### Can I limit what my agent is allowed to do with the Checkly Public API?

Yes. Because you run Jentic One yourself, you decide which Checkly operations your agent may call, so you can allow read and trigger calls like GET `/v1/checks/{id}` and POST `/v1/checks/{id}/trigger` while excluding DELETE `/v1/checks/{id}` unless you add it. Since the check id sits in the URL path, a rule can pin the agent to a single check so it can read and trigger that one check and nothing else. Your Checkly bearer key and account id stay encrypted in your own instance and are injected at execution time, so the agent never sees the raw credentials.