How often does an unattended job actually fail?
Nobody publishes this, so here are our own numbers: 9,342 runs by 94 scheduled agents over 30 days, with every alert broken out by kind. Measured, not estimated, and rebuilt from the production database every week.
The rate is boring. The kinds are not.
0.4 percent of runs ended in failure: 40 out of 9,342. If you were expecting worse, that matches most fleets, and it is also why people underestimate the problem. A crash is loud, rare and easy to catch. It is not what costs you a night.
Those 9,342 runs produced 77 alerts in total. Here is what they were:
| Kind | Count | What it means |
|---|---|---|
| FAILED | 40 | exited non-zero, or the client reported failure |
| MISSED | 25 | the run never started: dead scheduler, expired auth, crash before the first line |
| DRIFT | 11 | cost or duration moved away from this job's own baseline, while nothing failed |
| BUDGET_RUN | 1 | one run went over its cost cap |
Read that table from the bottom up
The rarest one is the one nothing else catches. 0 runs reported success while the file, URL or assertion they promised was not there. Every heartbeat monitor in this category would have counted those as green, because the job did check in. It just did not do anything. That is the failure mode people only discover downstream, when someone asks where the data went.
The second most common one has no category. 11 alerts were drift: cost or duration moving away from the job's own baseline while nothing failed at all. No exception, no missed run, no red status. A job that quietly starts taking four times as long is the earliest warning you get, and almost nothing watches for it.
Only 25 were the one everybody monitors. A run that never started is what a dead man's switch is for, and it is the minority of what actually goes wrong.
What these numbers are not
This is one fleet: 94 scheduled jobs that run a data business, mostly small scrapers, refreshes, health checks and report builders, plus a handful of LLM jobs. The median run takes about a second. A fleet of long agent sessions would fail more often and differently, and anyone who tells you there is one industry failure rate is selling something.
Two more honest limits. The record is built from what each client reported, so a client that lies about its own cost produces a faithful record of the lie. And a job nobody registered produces no alerts at all, which is the one failure mode monitoring can never see.
Why we can publish this at all
Because the runs behind it cannot be edited afterwards. Each finished run is hashed, each day of hashes is sealed into a Merkle root, and each root is chained to the day before and anchored in Bitcoin. So this page is not a marketing claim about our own reliability, it is a number you can recompute: verify a real run yourself, no account needed.
The dashboard version of the same measurement, with the median time to alert and the proof chain, is on in numbers. The fleet itself is live on a real fleet.
If you want your own numbers
Wrap one job and you have a baseline within a week. Free for 3 agents, all detectors on, no card: get a free key.
Use these numbers
They are free to quote, with attribution, under CC BY 4.0. The same figures are machine readable at /api/failure-rates.json, rebuilt every week from the production database, with the method and the limits in the file itself.
RunVouch (2026). How often does an unattended job actually fail?
9,342 runs by 94 scheduled agents over 30 days, measured 2026-10-26.
https://runvouch.com/how-often-jobs-failQuoting it in something that has to stay true? Use the frozen copy of the month, which stops changing when the month does: /api/failure-rates-2026-10.json. Months published so far: 2026-09, 2026-10.
Check it before you quote it. Every run behind these counts is hashed into a public daily Merkle root, chained to the day before and anchored in Bitcoin: the day files are at https://api.runvouch.com/proof/ and you can recompute one in your browser at /verify. The fleet that produced them is public run by run at /fleet/datasignals. If a number here moves, the chain says whether the history moved with it.
Writing about agent reliability and want something specific broken out, per kind, per job type or over a longer window? Ask on contact and we will run the query and publish the answer here.
Figures from the production database on 2026-10-26, over the preceding 30 days. TEST alerts excluded. Nothing on this page is typed in by hand.