What a 15-minute recovery target actually costs to run

A prospect once asked us, near the end of a call, how fast a broken feed would come back. We said fifteen minutes. He nodded like we had said something small, wrote it in his notes, and moved on to pricing. We understood the reflex. Fifteen minutes feels like a rounding error. It reads like a promise you make with a shrug.

Then we went and built the thing that keeps that promise, and the shrug turned into a line item that never really goes away.

The promise is not about speed, it is about noticing

Fifteen minutes to recover assumes you already know something is wrong. That is the part people skip past. The clock does not start when a human happens to glance at a dashboard. It starts the moment the feed stops behaving, and if nobody is watching at 3am on a Sunday, the clock is meaningless.

So the first cost is detection, and detection means people. Someone has to be on call. That is a rotation, a pager, a set of expectations about how quickly a person answers when their phone lights up. It is compensation for the interruption, and it is the quiet tax of knowing you might be interrupted, which is its own thing to carry. You can spread it across a team so no one person burns out, but spreading it does not make it free. It just makes it survivable.

Alerting is where the subtle money hides

Once you have people, you have to tell them the right things. This sounds simple and it is not.

The naive version alerts on errors. A request fails, you get paged. The problem is that the worst failures do not throw errors. A source quietly changes a page layout and your extractor returns zero rows, cleanly, with a green checkmark. Nothing crashed. The feed is broken and every system reports that all is well. If your alerting only watches for errors, you will find out about that failure when the client does, which is the exact outcome the fifteen minutes was supposed to prevent.

So you build alerting that understands what normal looks like. You alert on the absence of data, on volumes that fall outside the usual band, on records that arrive but fail validation. Each of those checks has to be tuned. Too loose and real breakage slips through. Too tight and the pager cries wolf until people stop trusting it, which is worse than no alerting at all, because now you are paying for it and ignoring it.

A pager that lies to you a few times a week is not an early warning system. It is furniture.

Tuning that balance is ongoing work. Sources drift, seasonal patterns shift, a client onboards a new region and doubles their expected volume overnight. The alerting is a living thing that needs attention, and attention is the recurring cost most people never quote for.

Recovery needs tooling you hope to never use

Say the alert fires correctly and the on-call engineer is awake and looking at the problem. Now you actually have to fix the gap, and fixing it in fifteen minutes is not something you improvise.

You need replay. When a feed stops for forty minutes, catching up is not a matter of restarting a job and letting it run forward from now. The forty minutes in the middle are still missing. You need to be able to re-run collection for a specific window, backfill exactly the records that were dropped, and stitch them into the stream without creating duplicates or gaps. That machinery has to exist before the outage, tested, or it is not there when you need it.

Here is the short version of where the ongoing bill actually lands:

• On-call rotation and the human cost of being reachable
• Alerting that watches for silence and bad data, and the constant tuning it demands
• Replay and backfill tooling, plus the redundancy to fail over while you repair

Collection is the cheap part

The thing clients imagine they are buying is the extraction. Fetch the page, parse it, store the rows. That part is real engineering, but it is bounded. You build it once, it runs, and its cost is roughly proportional to volume in a way you can predict.

Everything above is what actually makes the fifteen minutes true, and none of it is proportional to volume in a comfortable way. It is proportional to how much you have promised not to fail. Two feeds and two hundred feeds need the same rotation, the same discipline around alerting, the same replay path that has to work at 3am. The extraction scales with data. The reliability scales with the promise.

When we quote a recovery target now, we quote the whole shape of it. Fifteen minutes is not a feature we toggle on. It is a standing commitment to be awake, to notice, and to have already built the tool we hope stays in the drawer. The number is small. What sits behind it is not.