Hear about a broken cron job the night it breaks.
Add one line to a scheduled job. If it doesn't check in on time, runs too long or reports a failure, Cronlight tells you by email, Slack, Telegram or a webhook.
How it works
-
Create a check
Give it a name, the job's schedule as a cron expression or a plain period like every six hours, the time zone the job runs in, and how late it may be before anyone hears about it. You get a ping URL.
-
Add the line
Put a curl call to that URL at the end of the job. If you also ping when the job starts, Cronlight can tell you how long each run took.
-
Go back to work
Cronlight keeps the clock. When a ping is late, a run takes too long or the job reports a failure, the alert goes where you told it to. When the job comes back, you get a second message saying so.
# before
30 2 * * * /opt/scripts/backup.sh
# after
30 2 * * * /opt/scripts/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://ping.cronlight.example/5b1e0c2a-8d3f-4e7a-9c61-2f4b8a0d7e13The && means the ping only goes out when the backup script exits cleanly. If the script fails, the ping never arrives, and Cronlight notices the silence.
30 2 * * * curl -fsS -m 10 -o /dev/null https://ping.cronlight.example/5b1e0c2a-8d3f-4e7a-9c61-2f4b8a0d7e13/start; /opt/scripts/backup.sh; curl -fsS -m 10 --retry 5 -o /dev/null https://ping.cronlight.example/5b1e0c2a-8d3f-4e7a-9c61-2f4b8a0d7e13/$?A /0 at the end counts as success. Any other number counts as a failure and alerts straight away. The full walk-through is the first guide.
Three things Cronlight watches for
-
It didn't check in
The backup was due to start at 02:30 and it's 02:46. Your grace period decides how long Cronlight waits before it says anything.
Late: nightly-backup hasn't started. It was due at 02:30, grace period 15 min.
-
It ran too long
The job sent its start ping and then nothing. Set a longest normal run and Cronlight tells you when a run goes past it, while the job may still be stuck.
Late: invoice-export started at 06:00 and hasn't finished. The usual limit is 20 minutes.
-
It reported a failure
The job sent a fail ping or a non-zero exit code. You hear about it at once, with the last lines of output if the job sent them along.
Failed: db-vacuum failed with exit code 3. Output: ERROR: could not connect to server.
Where alerts go
Each check can send to one or more places, so the backups can go to the on-call chat while the reporting jobs go to email.
- Plain text. The subject line starts with the check name, so a mail filter can sort them.
- Slack
- Connect the Slack app once and pick a channel per check. Alerts and recoveries arrive in the same thread.
- Telegram
- Add the Cronlight bot to a chat or group and send it the code from your settings. Good for a phone that stays on at night.
- Webhooks
- A JSON POST for every alert and recovery, signed with HMAC-SHA256 so your own tools can check it came from Cronlight.
Pricing
-
Solo
Free
- One person and a handful of servers.
- 15 jobs
- 1 seat
- Email and Telegram alerts
- 7 days of ping history
- The API
-
Team
€19 / month
- A small team with jobs spread over a few servers or a cluster.
- 150 jobs
- 5 seats
- Email, Telegram, Slack and webhooks
- 90 days of ping history
- Projects, to group checks and route their alerts
- Our standard data processing agreement
-
Studio
€59 / month
- Agencies and teams looking after other people's servers.
- 1,000 jobs
- 15 seats
- Everything in Team
- A year of ping history
- Checks that create themselves on their first ping
- A log of who changed which check
- Invoices paid by bank transfer
Cronlight is made up, so there's no account to open. The team form shows how a request would reach the studio. See the team form
Prices are in euro, per month, before VAT. Every plan watches for all three kinds of trouble and has the API. Paying yearly costs ten months.
Inside Romania the invoice adds Romanian VAT. With a valid VAT number from another EU country, the invoice uses reverse charge. Cancel any month from your settings; we delete your checks and their history 30 days after the plan ends.
For more than 1,000 jobs or more than 15 people, tell us about your team and we'll set limits that fit. Ask about a team plan
Your data stays in the EU
Cronlight runs on servers in Germany, rented from a European hosting provider. Backups go to a second data centre in Finland. Nothing that stores your data runs in a US cloud region.
For each ping we keep the time, the address it came from, the user agent and whatever text you choose to send in its body, up to 10 KB. That's all we need to tell you a job is late, and it's deleted when it falls out of your plan's history.
The app has no trackers and no advertising scripts. Every paid plan can sign our standard data processing agreement.
Who makes it
We're a three-person software studio in Cluj. Most of our work is building and looking after software for other companies, which means a lot of servers and a lot of scheduled jobs that aren't ours.
Cronlight started as a script we wrote for ourselves after a client's nightly backup stopped running and nobody noticed for three weeks. The server had been moved, the crontab didn't come with it, and nothing complained. We've been adding to that script ever since, and now it's the product.
Questions
-
Where is my data kept?
In the EU. The servers are in Germany and the backups are in Finland, both with a European hosting provider. We don't copy your data to any US cloud region, and the alert emails go out through an EU mail provider.
-
What happens when Cronlight itself is down?
Your jobs keep running: the ping goes out after the job has done its work, and curl gives up after its time limit. Pings sent while we're down are lost unless curl's retries outlast the problem. When we come back, missed-job and run-time alerts wait one grace period before they fire, so a gap on our side doesn't wake you up for a hundred jobs that ran fine. We're three people. One of us is on call each week, and our own servers are watched by a separate monitor that runs outside them. We don't publish an uptime figure and we don't sell an SLA. When something breaks on our side, we write it up in the changelog.
-
Will the extra line slow my job down or break it?
The ping is one small HTTPS request at the end of the job. With
-m 10each attempt gives up after ten seconds,--retry 5caps how often it tries again, and the job's own work is already done by then. If you'd rather never see a curl error in cron's mail, add|| trueafter it. -
Do I have to send you my job's output?
No. A ping can be empty. If you do send text in the body, up to 10 KB, it shows up in the alert, which saves you logging in to a server at night to find out why the job failed.
-
Can I create checks without clicking through the dashboard?
Yes. Every plan has the API, so checks can come from a script or your infrastructure code. On Studio a ping to an unknown slug can also create its check, paused until someone names it and sets a schedule.
-
How do I pick a grace period?
Start with how late the job can be before it actually matters to anyone, then look at how long a normal run takes. There's a whole guide on it, with examples for jobs that run every minute and jobs that run once a night.
-
Can I cancel?
Any month, from your settings, with no call to arrange. Your checks keep working until the end of the month you paid for, and we delete them and their history 30 days later.