How-to guides
Three end-to-end walkthroughs that stitch the pieces together.
1 · Monitor a backup, and catch the empty one
The dangerous failure is not the backup that crashes. It is the one that runs, exits 0, and writes nothing. Send a /start, do the work, then ping success with a size metric. Add a floor rule (bytes ≥ 1, or better, a realistic minimum) so a zero-byte dump goes down even though the job "succeeded".
#!/usr/bin/env bash set -euo pipefail TOKEN=<token> curl -fsS "https://pulsewatcher.up.railway.app/ping/$TOKEN/start" # mark the run in-flight rows=$(pg_dump mydb | gzip | wc -c) # do the work, measure it if [ "$rows" -eq 0 ]; then curl -fsS "https://pulsewatcher.up.railway.app/ping/$TOKEN/fail" # nothing dumped -> fail now exit 1 fi curl -fsS "https://pulsewatcher.up.railway.app/ping/$TOKEN?bytes=$rows" # success + the byte count
In the dashboard, open the monitor → Metrics and add a floor on bytes. Now a shrinking or empty backup alerts you the same night, not at restore time. Full parameter rules are on the pinging page.
2 · Wire an alert into an auto-restart
Add a webhook channel to a monitor, point it at your receiver, and turn a monitor.down into an action. Always verify the signature first (see the webhooks page), then react to the event:
import { exec } from "node:child_process"
// receiver verifies the signature (see the Webhooks page), then:
app.post("/hooks/pulsewatch", (req, res) => {
const { event, monitor } = JSON.parse(req.body)
if (event === "monitor.down" && monitor.name === "queue-worker") {
exec("systemctl restart queue-worker") // heal, then let the up alert confirm
}
res.status(200).end()
})Keep humans in the loop for anything you cannot safely auto-heal: route those channels to email or Telegram instead.
3 · Publish a status page and a README badge
On a paid plan, toggle Show on status page for the monitors you want public, then share your status page slug. Each monitor also exposes a live SVG uptime badge you can drop into a README:
The badge and the status page are driven by the same checks, so they never disagree with your dashboard. Pick carefully what you publish: a public status page exposes the monitor name and its uptime history.