Why cron jobs fail: 21 million runs analysed

We analysed every call of 9,224 cron jobs over 12 days. The result: the vast majority of cron jobs simply run. Failures come almost entirely from a few that are permanently broken – and for the rest they are mostly brief hiccups that sort themselves out on the next call.

Period 4–15 October 2026 20,961,525 calls 2,282 domains How we counted

Eight in ten cron jobs run without a single failure

7,368 of the 9,224 cron jobs did not fail a single time in 12 days, and another 1,108 failed on fewer than one in a hundred calls. Permanently broken – at least every second call failed – were 545 cron jobs, 410 of them on every single call.

  • 79.9% no failures (7,368)
  • 12.0% under 1% failures (1,108)
  • 2.2% 1 to 50% failures (203)
  • 5.9% 50% failures or more (545)

Five percent of cron jobs cause almost all failures

Counting all calls together, 9.1% failed. That sounds like a lot but says little: the 462 cron jobs with the most failures – 5 percent of all – account for 99.7% of them. Without the permanently broken cron jobs the failure rate is 0.3%, about three in a thousand calls.

What these cron jobs have in common: mostly the address no longer exists. For 305 of the 545 permanently broken cron jobs the server answered 404 – the site was rebuilt or the domain changed, and since then the cron job has been calling into nothing.

That is why we report the change: one message when a cron job fails and an all-clear when it works again – instead of the same failure email every minute. About failure notifications

What knocks healthy cron jobs off track

More interesting than the permanent failures are the hiccups of cron jobs that otherwise run reliably. Of the 8,679 cron jobs with less than 50 percent failures, this many had the following error at least once:

  • Error in the script (500) 470 The script crashed – a PHP error, too little memory, a database that briefly did not answer.
  • Connection dropped 303 The server closed the connection midway, often under load or because of a firewall.
  • Server overloaded (503) 237 The web server refused because it was too busy or under maintenance.
  • Empty reply 186 A connection, but no answer: usually a process the host killed.
  • Upstream without an answer (502) 155 A proxy or CDN in front of the server got nothing usable from it.
  • Connection refused 136 Briefly nothing accepted connections at the address, for example during a restart.
  • Encryption failed 96 The HTTPS connection could not be set up, for example while a certificate was being replaced.
  • Server unreachable 55 No connection within the waiting time – a network fault or the server was down.

A cron job may have had several of these errors. Troubleshooting: what is behind each status code

Two in three hiccups happen only once

Of 9,013 failure phases, 6,035 (67%) consisted of exactly one failed call – the next one worked again. The server was briefly overloaded, restarted, or the connection dropped. A second attempt a few minutes later would have got the job done.

That is exactly what the automatic retry from Plus is for: on errors where your script certainly did not run, we try again after 1, 5 and 15 minutes – from another one of our servers. You only get a message if that does not help either. How retries work

When a protection service stops the call

For 34 cron jobs a Cloudflare security check stood in the way – together more than 150,000 calls held up. The script behind it never started once, and the status code alone does not tell you why.

We recognise the checks of Cloudflare, Vercel, Sucuri, Imperva and DDoS-Guard and say in the log which service it was and which exception you need to set up there – instead of just “403”.

How long cron jobs run

Half of all cron jobs finish within 4.4 seconds on average, 1,227 take less than a second. At the other end, 1,024 cron jobs run longer than 30 seconds on average – mostly imports, exports and backups. For them the time limit matters: whoever reaches it is cut off, and the script stops halfway.

With us a call may take 45 seconds on the free plan and 60 seconds from Plus. From Unlimited, the runtime statistics show whether a cron job is slowly growing towards that limit. Compare plans

What we do so your calls get through

Some failures are not caused by the script but by the way there: firewalls that block unknown senders, protection services, changing addresses. The only remedy is care in how the calls are made.

  • Fixed addresses to allow

    Our calls come from a fixed, published list of IPv4 and IPv6 addresses and always carry the user agent “Cronjob.de”. Hosts and firewalls can allow us specifically. Address list

  • Several servers in three locations

    Calls are spread across independent machines in Nuremberg, Falkenstein and Helsinki. If one fails, the others keep going.

  • IPv4 first

    Many firewall allowlists only know IPv4. On our servers with a fixed IPv4 address 0.55% of calls were rejected with “access denied”, on the others 1.05% – since September 2026 all of them prefer IPv4.

  • A second attempt from elsewhere

    The retry deliberately comes from another server with a different address. If the problem lies on the route between two data centres, it often works from there.

  • Addresses like a browser

    We encode spaces and special characters in the address the way every browser does, and convert domains with umlauts ourselves. Otherwise such addresses often fail with no answer at all.

  • An answer is not yet a success

    On request we check whether the answer contains a certain text – or an error message. That way even a script that stops with “200 OK” gets noticed.

How we counted

  • The basis is every call from 4 October 2026 to 15 October 2026, counted per cron job and day. We do not have complete figures for earlier days.
  • A failure is any answer with an HTTP status of 400 or higher, any connection that could not be set up or broke off, a protection service’s security check and a failed response check.
  • Not counted are our own services and heartbeats, where your server checks in rather than us calling it.
  • A failure phase is the same error in a row until a call succeeds again. Counted are phases that began within the period.
  • We name neither customers nor domains. All figures are totals across all accounts.

Common questions

How often does a cron job normally fail?
Rarely. For cron jobs that basically work, 0.3% of calls failed in our analysis – about three in a thousand. Eight in ten cron jobs did not fail a single time in 12 days.
What is the most common cause when a cron job does not run?
For cron jobs that otherwise run, it is the script itself crashing (HTTP 500). For cron jobs that fail permanently, it is mostly an address that no longer exists (404) – the site was rebuilt and the cron job still points to the old file.
Is it worth retrying a failed call?
Often, yes: 67% of failures happened once, and the next call worked again. But only retry when the script certainly did not run – for example on 502, 503 or a refused connection. After a 500 or a timeout it may already have done half its work.
Why does Cloudflare block my cron job?
Cloudflare treats calls without a browser as bots and shows a security check that a cron job cannot solve. The fix is a WAF rule with the action “Skip” for the cron job’s address. If “Bot Fight Mode” is on, the only fix is to switch it off.

Notice when a cron job fails

Five cron jobs are free forever. For the first 14 days you can try everything, including failure alerts and retries.

Start for free See pricing