Lists the checks in the project the API key belongs to, newest state first. API keys are per project, so this never spans projects. Descriptions are omitted here — call get_check for one.

Fetches one check with all its fields, including the description and the keyword filters. Accepts a UUID, or the unique_key that a read-only API key returns in place of one.

Lists recent pings of a check, newest first. The instance caps this at 100 pings on a free plan and 1000 on a paid one, and there is no pagination, so older pings cannot be reached at all. Note: Healthchecks requires a read-write API key for this endpoint even though it only reads. A read-only key is refused with HTTP 401 "wrong api key", which is not what it sounds like. Call get_api_key_info to check which kind is configured.

With a read-only key this tool cannot even be called correctly: it addresses a check by uuid, and a read-only key never sees one — list_checks answers with a 40-character unique_key instead. So the refusal you get first is about the argument, not the key. Neither is a mistake to fix: with a read-only key this endpoint is out of reach, and there is nothing to pass that would change it.

Returns the body that was POSTed with one ping — usually the output of the job that reported in, which is the fastest way to see why a check failed. Truncated at 64 KB. Note: Healthchecks requires a read-write API key for this endpoint even though it only reads. A read-only key is refused with HTTP 401 "wrong api key", which is not what it sounds like. Call get_api_key_info to check which kind is configured.

With a read-only key this tool cannot even be called correctly: it addresses a check by uuid, and a read-only key never sees one — list_checks answers with a 40-character unique_key instead. So the refusal you get first is about the argument, not the key. Neither is a mistake to fix: with a read-only key this endpoint is out of reach, and there is nothing to pass that would change it.

Lists the up/down transitions of a check — the history behind its current status. The instance keeps the current month and the two before it. Accepts a UUID or a unique_key.

Lists the notification integrations of the project, with the UUIDs that create_check and update_check accept in their channels argument. Integrations themselves can only be created in the web UI. Note: Healthchecks requires a read-write API key for this endpoint even though it only reads. A read-only key is refused with HTTP 401 "wrong api key", which is not what it sounds like. Call get_api_key_info to check which kind is configured.

With a read-only key this tool cannot even be called correctly: it addresses a check by uuid, and a read-only key never sees one — list_checks answers with a 40-character unique_key instead. So the refusal you get first is about the argument, not the key. Neither is a mistake to fix: with a read-only key this endpoint is out of reach, and there is nothing to pass that would change it.

Lists the status badge URLs of the project, one entry per tag plus "*" for the project as a whole. The plain variants treat a check in its grace period as up; the ones suffixed 3 report up, late and down separately.

Checks that the configured Healthchecks instance is reachable and its database is answering. Needs no API key, so it is the tool to try first when something is not working.

Reports which instance is configured, whether the API key works, and whether it is a read-only or a read-write key — which decides whether list_pings, get_ping_body and list_integrations can be used at all, and whether checks are identified by uuid or by unique_key.

Creates a check. Pass either timeout (a simple period) or schedule (a cron or systemd OnCalendar expression), never both. Unless channels says otherwise, the new check notifies every integration in the project ("*"), because a check with no integrations never alerts anyone. Setting unique turns this into an upsert that may UPDATE an existing check.

Updates a check. Fields that are not given stay unchanged. Two exceptions: channels REPLACES the integration list rather than adding to it, and setting schedule on a check that used timeout switches it over. Needs a UUID, which read-only API keys never see.

Pauses a check: it stops expecting pings and stops alerting. resume_check puts it back, and nothing is lost in between — so this is not asked about. It does mean a job that stops running goes unnoticed while the check is paused.

Resumes a paused check and puts it back into the "new" state, waiting for its next ping. Fails with HTTP 409 if the check is not paused.

Deletes a check permanently. Its UUID is not recoverable, so every deployed script pinging that URL breaks. Two-step: the first call returns a confirmation token, the second call with that token deletes.