Know when a routine stops running

An uptime checker fetches your site. HookPulse never fetches anything of yours: your routine calls our private URL, and silence for longer than the interval is the miss. That is what catches a cron that stopped, a backup that never finished or a scenario that was paused.

Every 5 minutes we compare each monitor with what it promised: the last ping against its interval (90 seconds to 24 hours), or, on a schedule, the time it was due plus its grace period. Past that we record a miss and alert once — by e-mail and by POST to your webhook URL — at most once per 24 hours, or per interval if it is longer. Because the check runs every 5 minutes, an alert can take up to 5 minutes to leave; that is a deliberate choice, not a hidden limit. The next ping clears it.

Yes. Give the monitor a five-field cron expression, an IANA time zone and a grace period in seconds (90 by default, 30 minimum) instead of an interval. A backup due at 03:00 in America/Sao_Paulo is late at 03:01:30 there, not a day later. The two are mutually exclusive: send a cron or an interval, never both. On the day clocks change, an hour that does not exist is skipped (the routine is not called late for a time that never happened) and a repeated hour matches once. An expression that never occurs within 366 days is refused when you create the monitor.

Yes. Add /start at the beginning of the routine and /fail at the end when it goes wrong, or just send the shell exit status: curl -fsS "$ORIGIN/in/ID/$?". Zero behaves like a normal check-in; 1 to 255 record the code as a failure. Neither /start nor /fail counts as proof of life, so a routine that starts and hangs still becomes a miss at the right time — and with /start we also record how long each run took. The failure alert leaves on the next 5-minute check, under the same one-alert-per-24-hours cap.

Set a maximum run time on the monitor and we alert while it is still hanging, instead of waiting for the next scheduled time. Open the run with /start and we know when it began; if it has not finished within the ceiling you set, the alert says the routine is still running. A success or a failure closes the run, so a job that finished never triggers it. The ceiling is between one minute and 24 hours, detection happens on the next five-minute check, and turning it off is sending zero.

Once a day by default, and you can change it per monitor. The minimum gap is one hour, so an incident can remind you hourly instead of daily; the maximum is 30 days, which is how you say tell me once and then stay quiet. Your check interval is always the floor: between two checks of a monitor that runs every two days there is nothing new to report, so the alert waits. The monitor shows the gap that will actually apply, not the number you typed.

The monitor page shows the median and the worst of the last runs we timed, next to the last one. A single number cannot tell a routine that is drifting slower from a day when the disk was busy; the median and the worst case can. We only count runs you opened with a start signal and closed, and the median is always a duration that really happened, never an average between two.

Only if you do not tell us which run is which. Add the same run identifier to the start and to the check-in that closes it, and each run is timed against its own start. Close a run we are not tracking and we leave the other one alone, still open and still watched against its maximum run time. Send no identifier and we close whatever is open, which is the right answer when only one run happens at a time.

Yes. The dashboard link also answers as a Prometheus scrape target, in the standard exposition format, with one series for how long ago each routine checked in, one for whether it is past its deadline and one counting how many times it went silent. Reading costs us nothing, so scrape as often as you like. The link is the credential, so treat it like a secret and rotate it if it leaks.

The alert identifies the routine and its last check-in. You can receive it by e-mail or through a connected app such as Slack or Discord. Integration details and the message format are available in /developers.

Yes. After an alert goes out, the next successful check-in sends a recovery message with when the outage started, when it recovered and how long it lasted. It has its own type (hookpulse.recovery) so an integration that filters by type never shows good news as an incident, and it arrives at the same destinations as the alert. It only exists after a real alert: a monitor that never went down is never told it came back. Both message formats are published at /api/templates.

Any HTTP request to the monitor's check-in link — GET from a crontab curl, POST from an n8n HTTP Request node, a fetch at the end of a script. Each hit is stored as an event and resets the clock. Pings are free and unlimited.

Ten monitors, intervals from 90 seconds, one e-mail alert destination, the status page and unlimited pings are free without an account. An extra monitor costs US$ 0.10, an interval under 90 seconds US$ 0.05 and an e-mail destination beyond the first US$ 0.10, per request (x402) or from prepaid credit. Sign in and confirm your e-mail for 90 days without usage charges for extra monitors and fast intervals. Additional e-mail alert destinations remain paid during the trial.

Yes. Ask for an ingest key once and point every job at /in/<key>/<name-of-the-job>: the monitor is created on the first check-in, and the same name always means the same monitor, so a retry never creates a second one. Creation only happens inside the free ten; past that the ping answers 402 and writes nothing. Rotating the key stops it from creating new monitors — the ones already created keep working.

No. Paste your crontab and we propose one monitor per scheduled line, with the cron expression already filled in — and nothing is written until you say so. The proposal also lists what was ignored and why: comments, variables and @reboot, which has no expected time. The command becomes the monitor name, with passwords and tokens removed first, because that name shows up in the alert e-mail, on the status page and on the badge.

Set paused_until on the monitor with the UTC instant the window ends, up to 30 days ahead. While it is paused the monitor is not checked and never alerts, and sending null resumes it. Pausing does not reset anything: the silence already accumulated and the last check-in stay as they were, so you can still see that the routine had stopped before the maintenance started. Do not remove the check-in link to pause — silence is exactly what we alert on.

No. This browser keeps a guest session and your monitors stay editable here. Sign in with your e-mail later and the monitors are claimed by your account, which also starts the 90-day trial. Agents pay per request instead.

Yes. This product's placements, the suggested 30-day price and the proposal form are at /partners; we reply within 3 business days.