Postmortem: the share-image 404

A small failure, written up properly, because the size of the failure is not what determines whether the write-up is useful.

Summary

qr-forge served a 404 on /favicons/og-image.jpg after its share-image and icon set merged. The set was corrected and re-verified, and the path now returns 200. (F-1, source: app-inventory sheet, qr-forge row notes, verified 2026-09-21)

Found on 2026-09-19 during a host verification pass, not by a report from anyone looking at it. On 2026-09-19 I ran a host verification pass on qr.bryancalabro.com, which found and fixed the share-image 404. (T-2, source: app-inventory sheet, qr-forge row notes, verified 2026-09-21)

Impact window

• Started: when the share-image and icon set merged. The exact merge time is not in my notes, so I am not going to state one.
• Found: 2026-09-19
• Fixed and re-verified: 2026-09-19

Impact was invisible to anyone using the app and visible to everyone who shared a link to it: the preview card rendered without its image. Nothing was down.

Timeline

• 2026-09-19 Host verification pass run across recently merged hosts.
• 2026-09-19 /favicons/og-image.jpg on qr.bryancalabro.com returns 404.
• 2026-09-19 The share-image and icon set is corrected and re-verified; the path returns 200.
• 2026-09-19 A second finding on the same merge is recorded: relative Open Graph URLs and an under-wired apple-touch icon. Its fix is not confirmed.

The deployment sweep that followed

Rather than fix one host and move on, I verified the hosts around it. Every figure below is from my own dated notes in the app-inventory sheet.

Four hosts over two days, all serving, all redirecting www correctly, one share image fixed. That is the whole of it. There is no cost figure, no request volume, and no deployment count on this page, because Cost and volume figures are not supplied. None reproduce from a repo or report in scope. (N-1, source: company/product-facts.md, section 3, verified 2026-09-21)

Contributing factors

The share image is the one asset on a page that the person building the page never looks at. It renders somewhere else, on someone else's crawler, after the link is already shared. Nothing in the local workflow surfaces it.

The check that would have caught it is one line of curl, and nothing was running that line.

What has not been confirmed

The second finding from the same merge, relative Open Graph URLs and the apple-touch icon wiring, is recorded as noted and its fix is not confirmed. It is carried openly on the quality desk's bug log rather than closed out quietly here.

Action items

• Fix and re-verify the share image on qr.bryancalabro.com. Done 2026-09-19.
• Add a share-image check to the rollback runbook. It is step 6 of the runbook.
• Build a scheduled crawl that checks the declared share image on every live host, so this is found by a machine next time.
• Confirm or close the relative Open Graph URL finding.
• Record the merge time for incidents like this, so an impact window can be stated rather than described.

What I would not write

A root cause sentence that sounds like a conclusion. The honest version is that nobody was checking, and nobody was checking because there was nothing to check with. That is now three pages of this network: a crawler, a runbook step, and this.