Know when your cron silently dies

Three things. Flat-rate pricing: a fixed monthly fee instead of pay-as-you-go, so the invoice never surprises you. Telegram-first alerts: DMs and group chats, linked with a single tap — no SMTP lag. And multi-region HTTP checks with quorum confirmation, so one flaky vantage point never pages you.

Full comparison with Healthchecks.io · with Cronitor

Pings are never dropped — breaking a heartbeat defeats the purpose. You'll get an email suggesting an upgrade. Only after exceeding the quota more than 3x for two months in a row (and a 7-day heads-up) do we suspend creating new checks — existing ones keep being monitored and keep alerting.

Anytime — the plan stays active until the end of the paid period, then the account drops to Free. Checks over the Free limit get paused, not deleted. You can export your data as JSON and delete the account yourself.

Yes. Ping bodies and HTTP check headers can carry sensitive data, so they are encrypted at the application level and purged when your plan’s retention expires. Everything travels over HTTPS only.

Delivery resilience: dashboard snippets include a fallback out of the box (curl url1 || curl url2), and SDKs fetch the current domain list from the API. Losing one domain loses neither pings nor your sleep.

Yes. systemd: ExecStopPost with $EXIT_STATUS and OnCalendar schedules. Laravel: a composer package with a scheduler macro. Kubernetes CronJob: curl as the last command of the container. Plus Python and Node packages.

Yes: project members with owner, admin and readonly roles. Invite a colleague by email from the project settings — the link is valid for 7 days, and if they have no account yet, the invitation applies automatically once they sign up and verify their email. Pro includes up to 5 members, Business has no member limit; plan limits apply to the owner’s account, not per member.

REST API v1: check CRUD, ping and event history, integration and pause management. Read-write and read-only project keys are issued in the project settings; a 600 req/min rate limit, an OpenAPI spec and static docs.

Grace is the allowance after the deadline: cron rarely fires to the second, and without it any drift would page you for nothing. Shortly after the deadline (with a small slack of up to 30 seconds, so second-long delays never blink) the check turns "late", and only once grace runs out does the "down" alert fire. An explicit fail signal alerts immediately, no waiting.

A monitoring service must be more available than what it monitors. The ping ingestion tier deploys and fails independently of the dashboard, and there are multiple ping domains. During a global outage on our side false down alerts are suppressed, and statuses are reconciled once we recover.

It is a dead man’s switch for scheduled work. The job sends an HTTP request to a URL of its own on every run, and the service raises the alarm when that request does not arrive in time. Note which way round it works: ordinary monitoring alerts on a bad answer, this one alerts on the absence of an answer — which is the only way to notice a job that never started at all.

Because none of the usual failures produce an error anyone sees. The crontab is wiped by a server migration, the file loses its execute bit, the job runs under a user without the right permissions, cron's minimal environment lacks a PATH your script assumed, or a stale lock leaves the run hanging. In every one of those cases nothing crashes and nothing is logged: the work simply stops happening, and the absence of an event is invisible from inside the machine.

Yes, and it is the usual reason people find us. wp-cron only fires when someone visits the site, so on a quiet site scheduled posts, backups and plugin updates silently stop. Move the schedule to a real system cron, add a ping to that line, and the black box becomes a check like any other.

How to set it up

Yes. Put curl as the last command of the container, or in ExecStopPost for a systemd unit, and the ping only goes out when the work actually finished. For a Kubernetes CronJob the same line at the end of the pod covers three different failures at once: the pod that crashed, the image that was never pulled and the node that never scheduled the job.

Ready-made snippets