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.
crontab
# add illari to the end of the crontab line
* * * * * /usr/local/bin/backup.sh && curl -fsS https://illari.dev/ping/abc123Three steps to a working monitor
1
Create a monitor
Name 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.
2
Ping it from your job
One HTTP request at the end of the job: curl, wget, a line of Python. GET, POST or HEAD, all fine.
3
Get alerted when it goes quiet
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.
If it can make an HTTP request, it can report to illari
cron, systemd timers, CI jobs, Kubernetes CronJobs, Windows Task Scheduler, a Lambda on a schedule, a scheduled AI agent. Anything.
crontab
# add illari to the end of the crontab line
* * * * * /usr/local/bin/backup.sh && curl -fsS https://illari.dev/ping/abc123backup.sh
#!/bin/bash
set -e
./run-nightly-etl.sh
# only pings if every command above succeeded
curl -fsS --retry 3 https://illari.dev/ping/abc123python
import urllib.request
do_the_work()
# ping on success
urllib.request.urlopen("https://illari.dev/ping/abc123", timeout=10)node
await doTheWork();
// ping on success
await fetch("https://illari.dev/ping/abc123");scheduled agent
# 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"illari CLI
# 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.
Built for real schedules
Timezone-aware schedules
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.
Grace periods
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.
Late, then Down
Two stages with separate alerts: a heads-up when a check-in is overdue, an escalation when it stays silent.
Alert channels
Email on every plan. Pro fans each alert out to Slack, Discord, Telegram, PagerDuty, incident.io, ntfy, Pushover, or a plain webhook.
Run data on Pro
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.
Pause and snooze
Deploying or doing planned work? Pause a monitor, or snooze it for a set window, and it stops checking and alerting until then.
Check-in history
The last 20 pings for every monitor, with timestamps and source IP, so you can see the pattern.
No agent, no SDK
The ping URL is the whole integration. The key in the URL is the credential; nothing else to set up.
Pricing
Flat tiers. No per-monitor metering, no per-seat pricing. The ping API and every language integration work on the free tier.
Free
$0forever
- 25 monitors
- Cron and interval scheduling, timezone-aware
- Email alerts, with recovery + hung-run notices
- Status badge, pause & snooze
- 14-day check-in history
Pro
$20/mo
- Unlimited monitors
- Cron and interval scheduling, timezone-aware
- Slack, Discord, Telegram, PagerDuty, incident.io, ntfy, Pushover & webhook alerts
- Late / Down / recovery / hung-run alerts
- Status badge, pause & snooze
- Structured run data: exit codes, duration, output
- Duration-anomaly and custom-metric threshold and baseline alerts
- Full run history on every monitor
- 90-day check-in history
Need invoicing or a custom arrangement? Email us.
Questions
How is this different from checking the exit code in my script?
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.
My job runs but sometimes does the wrong thing. Does illari catch that?
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).
Do I need to install anything?
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.
Can a coding agent set this up?
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.
Can I monitor a scheduled AI agent?
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.
What happens if illari goes down?
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.
The pipeline that got slower every week
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.
Keep cron monitoring in the same repo as the cron jobs
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.
Your scheduled AI agent can finish clean and still be wrong
An agent can post a confident summary and still have updated nothing, run out of turns mid-task, or burned the budget for no result. What to measure so the run's own numbers tell you.
Point a scheduled job at illari
25 monitors free. About two minutes to the first alert.