Skip to main content

Cron heartbeats

A backup that stopped running does not fail loudly; it simply stops. Cron heartbeats catch that class: the job tells Wakora every time it finishes, and Wakora raises an incident when the telling stops. This is independent from the agent's cron monitoring, which watches the cron daemon itself and counts jobs that exit non-zero (see Monitoring cron). A heartbeat covers the job that did not start at all, on any machine, with or without an agent.

Setting up a job​

Alerting, Heartbeats tab, New job. Give it a name, the expected interval (how often it should run), a grace period (how late is still fine) and a severity: warning by default, critical for a job whose silence should go up the escalation ladder and ring a phone (the nightly backup of the only database, not the weekly report). The console shows the job's ping URL, unique to that job. Make the job's last step fetch it:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS "<your ping URL>" > /dev/null

The && matters: the ping is sent only when the job succeeded, so a job that runs and fails looks the same as a job that did not run, which is what you want to hear about. The URL is plain HTTPS on app.wakora.io; any client that can make a GET request works, including wget, a PowerShell Invoke-WebRequest on Windows, or a scheduler's built-in webhook step.

How silence is judged​

  • A job you created but never pinged stays unarmed. Nothing fires while you are still wiring it up.
  • After the first ping the job is armed. When more than interval plus grace passes without a ping, an incident opens, named after the job, with the severity you gave the job. The severity is read when the incident opens: raising a job to critical applies to its next silence, not to an incident already open.
  • The next successful ping resolves the incident. A job that resumes does not need anyone to click anything.
  • The last ping time is shown on each job row, so a job that pings too often or at the wrong hour is visible before it becomes a problem.

Where it fits​

A heartbeat is a server-side feature: the incident is raised on the platform, not by an agent, and it survives the agent on that host being down or absent. That also makes it the right tool for jobs on machines you cannot install an agent on, and for jobs that run somewhere else entirely (a CI pipeline, a serverless function).

Jobs can be created and listed over the REST API (/heartbeats, with severity; the response carries the ping URL), which is how a provisioning script registers a heartbeat for every job it deploys.