When the out-of-band render of a prerendered page fails, what is served next, and why can that failure go unnoticed?

## A refresh is a publish The out-of-band render has one job: produce a complete document and replace what is stored for that path. If it does not produce a complete document, there is nothing to publish, and implementations typically take the conservative branch — **keep what is there**. The reasoning is straightforward: - The stored copy is known to be renderable output; the failure says nothing about its validity, only about its age. - Replacing it with a failure would convert a background problem into a user-visible outage on a page that was working a second ago. - Deleting it would push every subsequent request down the no-copy path, which is strictly worse than serving something slightly old. So the failed render is discarded, the old copy stays in service, and the path is refreshed again the next time it is due. ## What the visitor sees Nothing. Specifically: - **The same fast response**, served from storage with no data access. - **A success status**, because a stored page is being returned successfully. - **Valid, complete HTML** — last week's HTML, but structurally fine. - **Content that has stopped changing**, which only a human comparing it against reality can notice. This is the asymmetry that makes the failure mode dangerous. Rendering inside the request fails loudly: the visitor gets an error and your error rate moves within seconds. Refreshing out of band fails silently, and the damage accumulates as content drift rather than as downtime. ## Why ordinary monitoring does not catch it | Signal | Does it move when refreshes fail? | |---|---| | Error rate for the path | No — stored copies are served successfully | | Time to first byte | No — possibly faster, since no render competes for CPU | | Request volume | No — demand is unrelated to the copy's age | | Uptime and health checks | No — the application is serving correctly | | Age of the stored copy | **Yes** — it grows without bound | | Render attempts succeeded versus failed | **Yes** — directly, if you emit it | The two rows that move are the two nobody instruments by default, which is why this failure is routinely discovered by a person noticing that a page still shows last month's banner. ## Bounding the damage 1. **Emit the outcome of every render attempt** — path, duration, success or failure, and the error. This is the signal that names the cause; without it you learn only that something is old. 2. **Track the age of each stored copy** and expose the worst age per surface. Age is the consequence a visitor actually experiences, so it is the number worth alerting on. 3. **Alert on age against the policy for that surface**, not on status codes. "No successful refresh for this path in an hour" is the alert that would have fired. 4. **Decide in advance what should happen when a copy is very old.** Continuing to serve it is usually right; for a surface where an old fact is harmful, the alternative is to stop trusting the copy and render in the request, accepting the latency and the possibility of an error. 5. **Make failures retry.** A single failed attempt should not take a path out of the refresh cycle, and a path stuck failing should be visible as such. ## When keeping the old copy is the wrong default Most of the time "serve something rather than nothing" is right. It stops being right when the *content* of the stale page carries an obligation — a price, an availability claim, a legal notice, a published deadline. There, silently serving an old page is worse than serving an error, because it produces commitments the system behind it will not honour. That is a judgment made per surface, and the rendering model cannot make it for you; what the model owes you is the visibility to notice that the copy has gone old. ## Where frameworks differ Frameworks vary in how much of this they hand you. Some report render failures through their own logging and expose nothing about copy age; some retry on a schedule of their own; some record a failure marker so a subsequent request can be handled differently. Partial publication of a half-finished render is the behaviour to check for specifically — most implementations replace the stored copy only after a render completes, but an implementation that streams output directly into storage has to answer what happens when the stream ends early. When you cannot determine the behaviour from documentation, it is worth establishing by experiment, because it is the difference between an old page and a broken one.