Docs

1. Create a monitor — give it a name, and optionally a cron expression + timezone.
2. Copy its ping URL (shown right after you create it).
3. Have the job call that URL when it finishes. For a crontab line:

* * * * *  /usr/local/bin/backup.sh && curl -fsS https://illari.dev/ping/YOUR_KEY

That's it. The monitor turns Up on the first ping and you'll get an email if a later one is missing.

Every monitor has a unique URL like https://illari.dev/ping/<key>. The key is both the identifier and the credential — anyone with the URL can ping the monitor, so treat it like a secret and rotate it (delete + recreate the monitor) if it leaks.

• GET, POST and HEAD all count as a ping — use whichever is easiest.
• A ping records the check-in, sets the monitor to Up, and recomputes when the next one is due.
• Success response is 200 OK. An unknown key is 404. More than 60 pings a minute for one monitor returns 429 — well above any real schedule.
• Use curl -fsS (or --retry) so a failed ping is visible in your job's own logs.
• Add a suffix (/start, /<exit_code>) to report how the run went — see Reporting run data.

Anything that can make an HTTP request works. Ping last, after the real work.

#!/bin/bash
set -e
./run-etl.sh
curl -fsS --retry 3 https://illari.dev/ping/YOUR_KEY

import urllib.request
do_work()
urllib.request.urlopen("https://illari.dev/ping/YOUR_KEY", timeout=10)

await doWork();
await fetch("https://illari.dev/ping/YOUR_KEY");

Invoke-RestMethod -Uri https://illari.dev/ping/YOUR_KEY -Method Get

Pinging only on success means a run that starts but exits non-zero looks the same as one that never ran — silent — which is usually what you want an alert for.

Add a suffix to the ping URL to report how the run went. All of these still count as a check-in — the monitor stays Up — but the extra detail shows on the monitor page (exit codes, duration and captured output are a Pro feature).

• POST /ping/<key>/start — mark the run as started. The next success or failure ping records the elapsed time as the run duration.
• POST /ping/<key>/<exit_code> — finish with an exit code. 0 is success; anything else is recorded as a failed run.
• POST /ping/<key>/fail — a failed run with no specific code.
• Any request body is captured (truncated to ~10 KB) — pipe in the last lines of your log or a summary line.

KEY=YOUR_KEY
curl -fsS https://illari.dev/ping/$KEY/start

if ./run-etl.sh > /tmp/etl.log 2>&1; then
  curl -fsS https://illari.dev/ping/$KEY/0 --data-binary @/tmp/etl.log
else
  curl -fsS "https://illari.dev/ping/$KEY/$?" --data-binary @/tmp/etl.log
fi

A monitor can have a cron expression (*/5 * * * *, 0 3 * * *, …) and an IANA timezone (UTC, America/New_York, …). illari computes each expected run from those, with daylight-saving transitions handled — a 0 2 * * * job doesn't double-fire or vanish on the changeover.

Leave the cron expression blank for an open-ended monitor: it just expects a ping at least every grace period seconds, with no fixed cadence. Good for jobs that run irregularly.

A buffer added on top of the schedule (default 300s) for network jitter and slow starts. With a cron expression, the deadline is next expected run + grace. Without one, it's last ping + grace. Raise it for jobs that are legitimately slow to check in; keep it small for tight schedules.

• Pending — created, no ping yet. Not being checked until the first one arrives.
• Up — last ping was on time.
• Late — the deadline passed with no ping. First alert email.
• Down — still silent well past the deadline. Second alert email.

A worker checks every 60 seconds, so a status change lands within about a minute of the deadline. Any ping puts the monitor straight back to Up and clears the incident.

Pause a monitor from its detail page during a deploy or planned maintenance — the worker skips it entirely, no status changes and no alerts. Resuming starts it fresh: the clock restarts from now, so time spent paused never counts as “late.”

Late and Down alerts always go to your account email. Pro can also fan them out to Slack, Discord, and a webhook — set the URLs under Settings.

• Slack / Discord — paste an Incoming Webhook URL; you get a short message with the monitor name, state, and a link.
• Webhook — any HTTPS endpoint. Gets a JSON POST with the event (late / down), the monitor, and its schedule.

A flapping monitor won't spam you: repeat Late alerts are rate-limited to one every few minutes. Down alerts always go through.

The Free plan includes 25 monitors, email alerts, and every feature in these docs. Check-in history is kept for 14 days.

Pro ($20/mo) adds unlimited monitors; Slack, Discord and webhook alerts; structured run data — exit codes, duration, and output capture, with duration-anomaly detection; and 90-day history.

See pricing for current tiers.