Docs — sigabrt

The URL

Every endpoint has its own, shown when you create it and on its edit page. The token in the middle is what identifies the endpoint.

https://sigabrt.dev/pulse/8f3c…/beat

The URL is the credential. Anyone who has it can report your job as healthy, so keep it out of anywhere that expands links — a chat message, a public repository, an issue tracker.

Methods

MethodResponseRecords a pulse

GET200Yes

POST200Yes

HEAD200No — so a link preview or scanner cannot fake one

Anything else405No

GET and POST behave identically. Use whichever your tooling reaches for — a bare curl sends a GET and that is fine.

Responses

200 Recorded. The endpoint is healthy until the next one is due.

{"message":"Ping received","status":"ok","timestamp":"2026-09-05T12:58:53Z"}

404 No endpoint has that token — usually deleted, or a typo.

{"message":"Endpoint not found"}

402 Free trial spent. The pulse was refused, not recorded.

{"message":"Free trial used up (10 heartbeats). Upgrade to keep this endpoint monitored."}

A refused pulse deliberately leaves the endpoint's last-seen time alone, so its status keeps telling you when the job was genuinely last alive.

Examples

crontab

0 3 * * * ./backup.sh && curl -fsS https://sigabrt.dev/pulse/8f3c…/beat

The && is the important part: the pulse only goes out if the job succeeded. A failed run stays silent, which is what triggers the alert.

shell script

#!/bin/sh
set -e

run_the_work

curl -fsS -m 10 --retry 3 https://sigabrt.dev/pulse/8f3c…/beat

A timeout and a couple of retries stop a momentary network problem from being reported as a dead job.

without curl

wget -q -O /dev/null https://sigabrt.dev/pulse/8f3c…/beat

When an alert fires

Each endpoint has an interval — how often a pulse should arrive — and a grace period — how late it may be before anyone is woken up. Both are counted from the last pulse received.

Healthy a pulse arrived within the interval

Grace overdue, but still inside the grace period — no alert yet

Down interval and grace are both spent — this is when the alert goes out

Endpoints are checked every 30 seconds, so an alert lands within about half a minute of the deadline passing. You get a second one when a pulse finally arrives and the endpoint recovers.

Alerts go out by email, by ntfy push, or both — per endpoint. Either way it is recorded in the endpoint's event log, which is not something you can switch off: the log is what the service saw.

Push notifications

Set a topic under Settings and install the ntfy app, or open ntfy.sh/<your topic> in a browser. Every endpoint set to push uses that topic; one can be given a topic of its own if you would rather keep it separate.

A topic on a public server has no password — the name is the password. Anyone who guesses it can read your alerts, and whoever runs the server can read them regardless, so keep the generated name rather than picking a memorable one, and expect nothing in a push beyond an endpoint name and a time.

Managing endpoints from a script

Not yet. The dashboard talks to a JSON API, but the only credential it accepts is a token that expires after a day and can only be obtained with your account password — which is not something to put in a script. Long-lived API tokens are needed first, and this page will grow a section when they exist.