ni-c/healthchecks-mcp

A Model Context Protocol (MCP) server for
Healthchecks, the dead man's switch for cron jobs and
scheduled tasks — it alerts you when a job stops checking in. Works against the
hosted service and against a self-hosted instance alike.
Lets MCP clients like Claude Code, Claude Desktop or Codex see which scheduled
jobs are healthy, read the output the failing one reported, and create or adjust
checks — with the irreversible operations behind a confirmation token and the
write tools switchable off entirely.
Fourteen tools is the ceiling, not the floor:
HEALTHCHECKS_ALLOW_TOOLS=essential registers a curated seven instead, and a
model picks the right tool far more reliably from seven than from fourteen — see
choosing which tools load.
What makes it different
**It reads the ping bodies.** get_ping_body returns what a job actually printed
when it reported failure. Every other question — which check is down, since when,
how often — is one step away from that one, and it is the endpoint the other
Healthchecks MCP servers leave out.
**Read-only API keys work properly.** Healthchecks hands a read-only key a
different object: no uuid, no ping_url, no channels — a 40-character
unique_key instead. This server addresses checks by either, and
get_api_key_info tells you up front which kind of key you configured and which
tools it cannot reach, rather than leaving you with a 401 missing api key for a
key that was sent.
**It never pings a check.** Pinging is how a job reports that it ran. A tool that
could ping would let a model make a dead job look alive, which is the one thing
monitoring must not allow — see Not exposed, on purpose.
**It knows where this API is sharp.** timeout and schedule cannot be combined
because the upstream silently discards one of them; tags are validated against
their space separator and keywords against their comma; a new check is given
every integration unless you say otherwise, because the API's own default is a
check that alerts nobody.
Requirements
- Node.js ≥ 22
- A **Healthchecks** project API key — Project Settings → API Access. Keys are per
project, not per account, and are exactly 32 characters long.
Configuration
| Variable | Required | Description |
| --------------------------- | -------- | ----------------------------------------------------------------------------------------------------- |
| HEALTHCHECKS_API_KEY | yes | Project API key. A read-only key works for part of the tool surface — see below |
| HEALTHCHECKS_URL | no | Site root of a self-hosted instance, e.g. https://hc.example.net. Default https://healthchecks.io |
| HEALTHCHECKS_READ_ONLY | no | true registers only the read tools |
| HEALTHCHECKS_ALLOW_TOOLS | no | Comma-separated tool names, list_* prefixes, or essential for a curated preset |
| HEALTHCHECKS_DENY_TOOLS | no | Same syntax; removed from whatever HEALTHCHECKS_ALLOW_TOOLS left |
| HEALTHCHECKS_INSECURE_TLS | no | true accepts self-signed certificates (scoped to this connection) |
| ELICITATION | no | false replaces the approval dialog with the two-call token. **Not prefixed** |
HEALTHCHECKS_URL is the site root, not the API root: https://hc.example.net,
not https://hc.example.net/api/v3. Both are accepted — the suffix is trimmed —
because the API documentation spells every example the long way.
> **Use https://.** Over plain http the API key travels unencrypted; the server
> prints a warning unless the host is local. For self-signed certificates prefer a
> proper internal CA over HEALTHCHECKS_INSECURE_TLS.
Without an API key the server still starts and lists its tools (so registries and
inspectors can introspect it), but every call except get_status fails with setup
instructions instead of reaching the API.
**Read-only keys.** Healthchecks gates three tools that only read — list_pings,
get_ping_body and list_integrations — behind a read-write key anyway. With a