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 ten 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.
More on choosing period and grace · Explain a crontab expression