The cron that nobody scheduled

Our application has a fallback: if no cron is configured, due jobs run opportunistically on ordinary web traffic, after the response has been sent so no visitor waits.

This is a good safety net and a terrible primary plan, and it took us a while to say so loudly enough.

What breaks

Renewals. Crypto payment watching. Domain re-checks. Key window rolls. Webhook retries. All of it waits for a visitor.

On a busy site you would never notice. On a new site — which is every site on its first day — a quiet Sunday means nobody renews, no transfer is credited, no domain is re-checked, and every one of those failures looks like a bug in something else entirely.

That is the expensive part. Not the missed work, but the misattribution. You spend an afternoon debugging crypto settlement when the actual fault is that nothing has run since Friday.

Why we kept the fallback anyway

Because the alternative is that a misconfigured install silently does nothing at all, forever, and the operator finds out from a customer.

A degraded mode that mostly works is better than a clean failure nobody sees. But only if the degradation is visible.

Making it visible

The health page distinguishes a real schedule from a manual test. It stays amber until the cron has fired twice, spread out in time, because one run proves you can execute the command and nothing more.

That distinction matters more than it sounds. "I ran it once and it worked" is the state most misconfigured crons are in — the command is correct, and nothing is calling it.

The general shape

If you have a fallback for a missing configuration, the fallback must not be silent.

Something has to say, continuously and somewhere a human actually looks, *this is running in degraded mode*. A log line does not count; nobody reads logs when nothing is wrong.

Otherwise the fallback quietly becomes the configuration, and you find out how well it works during your first incident.