Grace period calculator
Too short and you are paged for a slow night until everyone ignores the alerts. Too long and you learn about a dead job hours late. Here is a defensible starting point.
Grace = worst run () + scheduler delay () + margin (), rounded up to something you would actually type.
Create a monitor with these Free for 25 monitors, no card.
This runs in your browser. Nothing you type is sent to this server.
What the two numbers mean
Period is how often a successful report is expected — the job's schedule, not its duration. Grace is how late that report may be before it counts as missing. They are separate because a job that runs daily and takes twenty minutes is normal, and a job that runs daily and has not reported after ninety minutes is not.
Adding them gives the number that actually matters to you: the longest it can take to find out. A daily job with a 30-minute grace means a failure at 02:00 is known by 02:30 the next day at the latest — but a job that dies at 02:00 today is known about at 02:30 today, because today's report never arrives.
Why the worst case, not the average
Grace is a threshold, so it is set by the tail, not the middle. A backup that normally takes ten minutes and occasionally takes twenty-five needs a grace built on twenty-five. Setting it on the ten-minute average guarantees a false alarm on the first slow night, and a monitoring system that cries wolf gets muted, which is strictly worse than not having one.
The margin exists for the night when the job is at its worst and the scheduler is at its slowest, which is more correlated than it sounds: both tend to happen when the machine is busy.
Scheduler delay is not a rounding error
Some schedulers start jobs within a second of the minute. Others do not, and the difference decides whether your alerts are trustworthy:
- cron or systemd on a machine you control — seconds, unless the machine is loaded.
- Kubernetes CronJob — scheduling, image pull and node capacity easily add minutes.
- GitHub Actions schedules — queued, not guaranteed. Runs on the hour can be delayed many minutes or dropped entirely, so allow generously and avoid
:00. - Hosted automation platforms — depends on their queue, which you cannot see.
Use the figures here as a starting point and replace them with what you measure. A monitor that records each run's duration gives you the real distribution within a fortnight.
When the numbers do not fit
If the grace a job needs is as long as the gap between its runs, no threshold will work well, and the tool says so rather than producing a confident wrong answer. The real fix is one of three things: make the job faster, run it less often, or accept a slower signal and alert only after two consecutive misses.
The other case worth noticing is a job whose worst run is many times its typical one. That variance usually means the job waits on something it does not control — a lock, an external API, a queue — and it is worth understanding before it is worth monitoring tightly.
Jobs that do not run at an even interval
A period assumes every gap between runs is the same length. Plenty of schedules are not like that. 0 9 * * 1-5 runs every weekday morning, so four of its gaps are 24 hours and the Friday to Monday gap is 72. A monthly job on the 1st varies between 28 and 31 days. A period of one day on that weekday job is correct from Monday to Friday and pages you every Saturday morning.
Give the monitor the cron expression instead of a period. Vivere then works out each next run from the expression itself, in your timezone, so the weekend gap is expected rather than alerted on. Paste the expression into the crontab explainer to check it means what you think, and it will hand it to a new monitor for you.
If you do use this calculator for an uneven schedule, enter the largest gap rather than the usual one. The grace it gives you is still right; the period it shows is only safe on the longest gap, which is why the cron expression is the better answer.
More on choosing period and grace · Explain a crontab expression