Cron Job SLA: A Practical Framework for Scheduled Tasks

Why 'Uptime' Doesn't Translate Directly to Cron Jobs

A web server's uptime SLA answers one question: did it respond when asked? A cron job SLA has to answer a harder one — did the right thing happen, on time, and completely — with nobody asking. A scheduled task can sit on a server with perfect uptime and still fail: the process crashes silently, the script hangs past its window, or the trigger never fires. None of that shows up in a server uptime dashboard.

This is why cron job uptime SLA thinking needs its own vocabulary. Scheduled task reliability isn't about whether infrastructure is reachable — it's about whether work got done. Building an SLA around that distinction is the only way to give stakeholders a number they can actually trust.

SLA vs SLO vs SLI: Applying the Framework to Scheduled Jobs

Borrowing from Google SRE practice clarifies the layers, but each needs a cron-specific translation. The SLI (Service Level Indicator) is the raw measurement — job success rate over a trailing 30-day window, or the percentage of runs that started within their grace period. The SLO (Service Level Objective) is the internal target set against that indicator: "our nightly billing job should succeed 99.9% of the time." The SLA (Service Level Agreement) is the external, often contractual commitment built on that SLO, with consequences attached — service credits, escalation clauses, or renewal risk if missed.

The cron SLA vs SLO distinction matters because teams often build monitoring for one and report the other. You can track an SLI internally, hold yourself to a stricter SLO than what you promise, and only publish the looser SLA number externally. Getting the SLA SLO SLI difference straight up front prevents confusing an aspirational internal goal with a binding external promise.

The Metrics That Actually Matter for a Cron SLA

Raw uptime percentage doesn't map cleanly onto scheduled work, so a cron reliability framework needs its own set of SLIs:

• Execution success rate — the job success rate SLA baseline: what percentage of scheduled runs completed without error over the measurement window.
• On-time start rate — the percentage of runs that began within an agreed grace period of their scheduled time, not just eventually.
• Completion within expected duration — a run that starts on time but hangs for hours can be as damaging as one that never starts; track duration against a baseline.
• Mean time to detect (MTTD) — how long between a missed or failed run and someone (or something) noticing.
• Mean time to recovery (MTTR) — how long between detection and the job successfully re-running or the issue being resolved.

These five give a far more honest picture of scheduled task reliability than a single uptime figure, separating "the trigger fired," "it ran on time," "it finished correctly," and "we knew fast enough to fix it" into distinct, measurable failure modes.

Doing the Math: Translating Uptime Targets into Job Terms

Standard uptime tiers were built for continuous availability, but you can reframe them as allowed missed or late runs per month by applying the downtime percentage against the number of scheduled runs rather than continuous seconds.

A daily job runs roughly 30 times a month. At 99.9% (three nines), you can miss about 0.03 runs a month — in practice, zero misses tolerated, with the fractional allowance mostly covering rounding. At 99.95%, the tolerance is roughly one missed run every six months. At 99.99% (four nines), you're allowed a miss so rare it approaches "never" for a monthly cadence.

An hourly job runs about 730 times a month, which changes the picture entirely. A 99.9% target there allows roughly 0.7 missed runs a month — call it one bad run every four to six weeks. At 99.95%, that drops to roughly one missed run per quarter. At 99.99%, you're back down to a handful of missed runs per year across the whole fleet of hourly jobs.

The takeaway: cron job SLA percentage targets need to be paired with job frequency before they mean anything. Promising "99.9% uptime" on a job that runs once a day and one that runs every five minutes represents two completely different reliability bars, even though the number looks identical.

Writing Your Cron Job SLA: A Practical Template

A usable cron job SLA template should specify, in plain language:

• Measurement window — 7, 30, or 90 days, stated explicitly and applied consistently.
• Definition of "failed" — non-zero exit code, timeout, exception, or missing expected output — pick a concrete rule, not "didn't work."
• Definition of "late" — the grace period after scheduled time before a run counts against on-time start rate.
• Duration ceiling — the maximum acceptable runtime before a completed job still counts as degraded.
• Exclusions — planned maintenance windows, deploys, or upstream provider outages that don't count against the number.
• Escalation path — who gets alerted, in what order, and what the expected internal response time is if this is an internal SLA rather than a customer-facing one.

Writing this down forces the team to define SLA for background jobs in specific, testable terms instead of a vague "it should just run."

What Belongs in a Reliability Report

A credible cron job monitoring SLA report needs more than a single success percentage. Include the success rate itself, the count and nature of incidents in the window, MTTR for those incidents, and a trend line comparing the current period to the last two or three — a flat 99.9% that's trending down from 99.99% tells a different story than one holding steady.

None of this reliability reporting is possible without execution history: timestamps for scheduled vs. actual start, duration, exit status, and alert/resolution timestamps for every run. Retry behavior also feeds directly into MTTR, which is why retry strategy — exponential backoff versus fixed intervals — belongs in the same conversation as your SLA numbers.

Measuring Against Your SLA (Without Building It Yourself)

Every metric above — execution success rate, on-time start rate, duration, MTTD, MTTR — depends on capturing execution history you probably aren't logging today: what was supposed to run, what actually ran, when, and for how long. Heartbeat monitoring and a dead man's switch pattern, where a job must check in or an alert fires, are the detection mechanism that makes MTTD possible in the first place; the mechanics of push-based health check pings explain how that check-in model works under the hood.

Cronevra is built specifically to supply this data: a cron job monitoring tool that logs every run's start time, duration, and outcome, alerts on missed or late executions inside your defined grace period, and gives you the execution history needed to track cron job reliability and produce the report you just outlined — without hand-rolling logging and alerting logic yourself. It also pairs naturally with CI/CD monitoring practices for teams treating scheduled automation as seriously as their deploy pipeline.

Once your SLA is written down, the only thing left is measuring against it consistently. Cronevra turns your execution history into the SLI data your SLA depends on — check the pricing page and start tracking your jobs against real numbers instead of guesses.

Frequently Asked Questions

What's the difference between an SLA, SLO, and SLI for a cron job?

An SLI is the raw measurement, like job success rate over 30 days. An SLO is the internal target you set against that measurement, such as 99.9% success. An SLA is the external, often contractual version of that target, with consequences attached if it's missed.

What uptime percentage should I target for a cron job SLA?

It depends on job frequency, not just the percentage itself. A daily job at 99.9% has almost zero tolerance for missed runs, while an hourly job at the same percentage allows roughly one missed run every four to six weeks — match the tier to how often the job actually runs.

Does a cron job that runs late count as a failure against the SLA?

It should, if it falls outside your defined grace period, even if it eventually completes successfully. Treating "late" as a separate SLI from "failed" gives a more accurate picture, since a job that always finishes but consistently starts late is a different problem than one that never runs.

How do I calculate allowed downtime for a scheduled job SLA?

Apply the downtime percentage to the number of scheduled runs in your measurement window rather than continuous time. For example, at 99.9% uptime an hourly job (about 730 runs/month) tolerates roughly 0.7 missed runs monthly, while a daily job (30 runs/month) tolerates close to zero.

Can I offer a customer-facing SLA for jobs I don't control the execution environment for?

Yes, but scope it carefully with explicit exclusions for factors outside your control, like third-party outages or customer infrastructure issues. Define what you're measuring — your trigger and detection layer — separately from environment factors you can't guarantee.

What metrics should go in a cron job reliability report?

Include execution success rate, on-time start rate, incident count, MTTR, and a trend comparison against prior periods. These require execution history data — start times, durations, and outcomes for every run — rather than a single uptime percentage.