Edge Observability: Seeing Storefront Errors Where They Actually Happen
Log at the edge as well as the origin, and tag every response with its cache status and region. Once a store serves real traffic from cache, origin logs alone miss the errors shoppers actually hit: stale variants, regional failures, and cache misconfigurations that never touch your servers.
A store moves traffic to the edge, page speeds improve, and then a strange support ticket arrives: a customer in one region sees a broken page that nobody can reproduce. The origin logs are clean because the origin never saw the request. The page came from cache, in one region, from a variant generated during a deploy three days earlier.
This is the observability trade of edge architecture: you gain speed by serving away from the origin, and you lose the single log file that used to explain everything. Closing the gap is a discipline, not a tool purchase. This post covers what to log at the edge, the cache metrics that predict trouble, and how to trace a shopper's request across both layers.
Log the edge response, not just the origin request
Every edge response should emit a log line with the fields origin logs never had: cache status (hit, miss, stale, revalidated), the region that served it, the variant keys involved such as device, language, and currency, and time broken into cache lookup, origin fetch, and delivery. Without the cache status field, a team cannot tell whether a bad page came from the application or from a copy made hours ago.
Sample intelligently. Full logging of every asset request drowns the signal and the budget; log all errors and slow responses completely, and sample successes at a rate that still supports regional comparisons. Keep the logs queryable by URL and by deploy version, because the most common edge incident question is what changed, and the answer is usually a configuration or content deploy with a timestamp.
Watch the metrics that fail before shoppers complain
Cache hit ratio by template is the vital sign. A sudden drop on product pages means a deploy, a cookie change, or a personalization feature is fragmenting the cache, and the origin load spike arrives a few minutes later. Track it by region as well as globally: a global average hides the one region whose cache is cold or misconfigured.
Error rates need the same split. A 500 rate that is flat globally can be a total outage in the region serving ten percent of traffic. Alert on regional error rates and on stale serving duration: serving stale for thirty seconds during an origin blip is the system working, while serving stale for six hours is an incident nobody paged because shoppers saw pages, just old ones.
Make one request traceable end to end
Give every request an ID at the edge and pass it to the origin on cache misses, logging it in both places. When a merchant reports a wrong price or a broken page, that ID turns a vague report into a lookup: which region, which variant, hit or miss, which deploy's copy. Support teams should be able to paste a shopper's URL and timestamp into a dashboard and get that story in one view.
Close the loop with synthetic checks from real regions. Probe the homepage, a product page, and a search page from the regions you actually sell in, every few minutes, and record what a shopper there would get, including the cached variant. The pairing of real request logs for depth and synthetic probes for coverage is what turns edge architecture from a black box back into a system you operate.
Related reading
Readers working through this topic often find these earlier guides useful as well: How Edge Personalization Works Without Slowing the Storefront Down, Cutting Checkout API Latency With Edge Proxies and Connection Reuse.
Frequently asked questions
Why do origin logs miss edge errors?
Because cache hits never reach the origin. A stale or wrong variant served from cache in one region produces a real shopper error with no corresponding origin entry, which is why edge side logging is essential.
What is the most useful edge metric to alert on?
Regional error rate and cache hit ratio by template are the two highest value alerts. The first catches regional breakage, the second predicts origin overload before it happens.
Should we log every request at the edge?
Log every error and slow response, and sample successful requests. Full capture of every asset is expensive and buries the incidents in noise.
How long should edge logs be kept?
Thirty to ninety days covers most incident investigations and deploy comparisons. Keep aggregated metrics far longer than raw logs so seasonal patterns stay visible.