A user-facing 5xx during an incident has at least four possible authors: your application, your origin infrastructure, the CDN’s fetch path, or the edge itself. Triage speed depends entirely on attributing the author fast, and the attribution is mechanical once the taxonomy is in your head and your logs.
The status codes with delivery dialects
502 from the edge means the origin answered wrongly (connection reset, malformed response, TLS failure on fetch), the conversation happened and went badly. 503 splits meanings: origin overloaded or health-checked out, versus the edge’s own admission control shedding load, versus your application’s deliberate unavailability; vendor-specific subcodes and response headers distinguish them, learn yours. 504 is the fetch timing out: origin too slow or path broken, the conversation never finished. And 520-class vendor-specific codes are the edge saying something origin-shaped went wrong that fits no standard bucket; their documentation pages are triage gold.
The attribution fields that settle it
Your unified logs (the multi-CDN logging article’s schema) should carry per-request: cache status, which tier served or erred (edge, shield, origin-fetch), origin connect and response timings, and the vendor’s error subcode. With those fields, one query separates edge-authored from origin-authored errors, and a second correlates origin-authored ones with your own infrastructure timeline. Without them, the incident channel argues about whose dashboard is lying, the precise meeting this article exists to abolish.
The error-budget integration elevates this from runbook to policy: once errors are attributed by author, your reliability targets can be layered honestly, the delivery tier’s error contribution measured separately from the application’s, each with its own budget and its own escalation. That decomposition changes vendor management (the CDN’s slice is now a measured series you bring to QBRs and SLA claims, per the logging article’s negotiation dividend) and changes internal prioritization (an application burning its budget cannot hide behind ambient delivery blame). Attribution is the precondition for accountability in both directions, which is why the logging fields above are not observability nice-to-haves but the substrate of every reliability conversation an estate with vendors will ever have.
The masking machinery
Well-configured delivery hides many 5xx entirely: stale-if-error serves yesterday’s content through origin trouble, origin failover (the multi-origin article) reroutes around regional failure, and custom error pages at least keep the failure branded. Monitor the masking itself, stale-served rate and failover activations are your true origin-health signals, firing before users see anything, and an estate serving stale at scale is in an incident whether or not the error dashboards agree.
In practice
Build the taxonomy card for your specific vendors (their subcodes, their header names), wire the attribution fields into logging now rather than mid-incident, alarm on stale-served and failover-activation rates as leading indicators, and rehearse one attribution drill: inject an origin failure in staging and time the path from first 5xx to correct owner paged. Minutes are achievable; the estates still measuring in meeting-lengths are choosing to.
Incident-readiness engagements here deliver the taxonomy card, the attribution queries and the timed drill. Triage becomes a lookup.