Your scheduled job, worker, or agent run pings a URL every time it runs. When a ping doesn't arrive on schedule (the job crashed, the box is down, the scheduler got wiped in a deploy), you get an alert.
No credit card. No agent to install.
# add illari to the end of the crontab line
* * * * * /usr/local/bin/backup.sh && curl -fsS https://illari.dev/ping/abc123Name it, then either give it a schedule (a cron expression or a preset) and timezone, or set it to just expect regular check-ins. You get a unique ping URL.
One HTTP request at the end of the job: curl, wget, a line of Python. GET, POST or HEAD, all fine.
Miss the window and illari alerts you: Late first, then Down if it stays silent. The next ping clears it and sends an all-clear.
cron, systemd timers, CI jobs, Kubernetes CronJobs, Windows Task Scheduler, a Lambda on a schedule, a scheduled AI agent. Anything.
# add illari to the end of the crontab line
* * * * * /usr/local/bin/backup.sh && curl -fsS https://illari.dev/ping/abc123#!/bin/bash
set -e
./run-nightly-etl.sh
# only pings if every command above succeeded
curl -fsS --retry 3 https://illari.dev/ping/abc123import urllib.request
do_the_work()
# ping on success
urllib.request.urlopen("https://illari.dev/ping/abc123", timeout=10)await doTheWork();
// ping on success
await fetch("https://illari.dev/ping/abc123");# a scheduled agent run: report the outcome and the numbers
python agent.py; code=$?
curl -fsS -m 10 \
-d "cost_usd=$(jq -r .cost run.json)" \
-d "tool_calls=$(jq -r .tool_calls run.json)" \
"https://illari.dev/ping/abc123/$code"# no edits to the script: the CLI wraps it
npm install -g illari
illari run --key abc123 -- ./nightly-etl.shPinging only after the work succeeds (as above) means a job that runs but exits non-zero shows up as silent, which is usually what you want. On Pro, send the exit code explicitly and illari alerts on the failure itself. The illari CLI sends the start ping, the exit code, and the output tail for you.
Using a coding agent? Point it at illari.dev/llms-full.txt and ask it to add monitoring to the scheduled jobs in your repo.
Give it a cron expression and an IANA timezone, or no fixed schedule at all. Expected run times are computed with DST handled, so no false alarms twice a year.
A small buffer on top of the schedule for network jitter and slow starts, so a job that's 20 seconds late isn't an incident.
Two stages with separate alerts: a heads-up when a check-in is overdue, an escalation when it stays silent.
Email on every plan. Pro fans each alert out to Slack, Discord, Telegram, PagerDuty, incident.io, ntfy, Pushover, or a plain webhook.
Send the exit code, run duration, output tail, and your own numbers on the same ping. Pro alerts when a run fails, runs far slower than its baseline, starts and never finishes, or reports a metric past a threshold you set.
Deploying or doing planned work? Pause a monitor, or snooze it for a set window, and it stops checking and alerting until then.
The last 20 pings for every monitor, with timestamps and source IP, so you can see the pattern.
The ping URL is the whole integration. The key in the URL is the credential; nothing else to set up.
Flat tiers. No per-monitor metering, no per-seat pricing. The ping API and every language integration work on the free tier.
Need invoicing or a custom arrangement? Email us.
You still have to be watching. illari watches for you, and it catches what your script can't report on at all: the scheduler never fired, the machine was down, the job definition got dropped in a deploy. No ping arrives, and you hear about it.
The free tier checks that the job checked in on schedule. Pro reads the run too: send the exit code, duration, output tail, and numbers like a row count on the same ping, and illari alerts you when a run fails, takes far longer than its baseline, or reports a value past a threshold you set (rows < 1, errors > 0).
No. One HTTP request from anywhere your job can reach the internet, no agent or SDK. There's an optional CLI (npm install -g illari) that wraps a command and sends the start ping, exit code, and output for you, but it isn't required.
Yes. The docs are published as plain markdown at illari.dev/llms-full.txt, with an index at /llms.txt. Point your agent at that URL and ask it to add illari to the scheduled jobs in the repo. It has the ping URL pattern, the event suffixes, and the metric-rule syntax.
Yes. An agent run is a run: ping the monitor URL when it finishes with the exit code, and send the numbers that describe a good run (cost_usd, tool_calls, rows_written). illari alerts if the run never checks in, exits non-zero, or reports a metric past a threshold you set, like cost_usd over 5. Same mechanism as a cron job.
illari runs on separate infrastructure from the jobs it watches. When your server, scheduler, or network fails, illari is on the other side of that failure, still running and able to alert you. Staying up while your side is down is the entire point of the service.
Four minutes in January, forty in April, a clean exit every night in between. Why gradual slowdown hides from monitoring, how to record run duration where a trend is visible, and how to alert on slower-than-usual.
What PagerDuty, Opsgenie, and Sentry Crons actually do out of the box for a missed cron job, and where each one falls short of a dedicated monitor: pricing, native detection, alert gating, and Opsgenie's sunset date.
Monitoring that lives in a dashboard drifts away from the jobs it watches: new jobs ship without a monitor, and changed jobs keep a stale one. Define the monitor as code, next to the schedule.
25 monitors free. About two minutes to the first alert.