Checklyhq Checkly Public API

Name: Checkly Public API
Brand: Checkly Public API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilitybearer8 EndpointsREST

For Agents

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

Install Jentic One Beta

Connect the Checkly Public API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Checkly Public API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Checkly Public API.

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

GET STARTED

Start building with Checkly Public API

Explore with Jentic

View OpenAPI Document

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.

Use Cases

Patterns agents use Checkly Public API for, with concrete tasks.

★ 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.

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.

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.

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.

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

Key Endpoints

8 endpoints — jentic publishes the only available openapi specification for checkly public api, keeping it validated and agent-ready.

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

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Checkly bearer API keys and X-Checkly-Account ids are stored encrypted in the Jentic MAXsystem vault. The agent never sees either value — Jentic injects both headers at execution time.

Intent-based discovery

Agents search Jentic by intent (e.g. 'trigger a check run' or 'create a synthetic check') and Jentic returns the matching Checkly operation with its input schema, so the agent picks among 8 endpoints without reading docs.

Time to first call

Direct Checkly integration: about a day for auth, request shape, and rate-limit handling. Through Jentic: under 30 minutes — search, load schema, execute.

FAQs

Specific to using Checkly Public API through Jentic.

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 at https://app.jentic.com/sign-up.

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 the MAXsystem vault 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 the MAXsystem vault.

Checklyhq Checkly Public API

Connect the Checkly Public API to your agent

Capabilities

Start building with Checkly Public API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs