Observability guide
Build a Unified Incident Timeline Across CDN, WAF, DNS and Origin
A unified timeline keeps source evidence intact while showing which relationships are exact, inferred, or only time-adjacent. That distinction prevents a dashboard from inventing root cause.
On this page
Separate provider consoles turn one failure into competing stories. A CDN may show cache misses, a WAF may show blocks, DNS may show an answer change, and the origin may show timeouts. The goal is not a single flat log stream. It is a source-attributed incident record that can show what happened, when it was observed, and how confidently events relate.
Overview
Outcome
Define a privacy-aware evidence model for DNS, CDN, WAF, bot, DDoS, and origin events, then use it to investigate user-visible impact from the edge back to the application.
Preserve provenance before normalizing fields
Keep the original event, source timestamp, collection timestamp, vendor, account, and schema version. OpenTelemetry's log model separates Timestamp from ObservedTimestamp; that matters when streaming delays or clock skew change the order in which an operator sees evidence.
- Source events
DNS, edge request, WAF, bot, origin, and configuration signals arrive.
- Raw evidence
Immutable source payloads remain access controlled.
- Normalised envelope
Timestamps, route, outcome, vendor, and identifiers are mapped.
- Correlation
Exact IDs and bounded inferences receive confidence labels.
- Incident timeline
Impact, changes, hypotheses, and recovery evidence stay together.
Raw evidence remains accessible while a normalised stream supports cross-provider questions and an explicit correlation confidence.
Correlate without inventing causality
Use a namespaced application request ID or W3C traceparent for an exact join. A provider request ID can create a strong same-provider link. DNS evidence usually cannot be tied to one HTTP request; associate it by queried name, resolver or client scope, answer, and a bounded time window, then label it contextual rather than exact.
| Confidence | Evidence | Safe statement |
|---|---|---|
| Exact | Same trace ID or namespaced immutable request ID | “These events describe the same request.” |
| Strong inference | Same provider ID, zone, and service | “The WAF decision is linked to this edge request.” |
| Temporal context | Same hostname and bounded incident window | “The DNS failure preceded the edge-error increase.” |
| Aggregate | Matching regional trend only | “These signals changed together; investigation continues.” |
{
"event.type": "waf.decision",
"event.time": "2026-07-15T10:12:08Z",
"event.observed_time": "2026-07-15T10:12:10Z",
"source.vendor": "edge-provider",
"correlation.request_id": "edge:req_01...",
"correlation.confidence": "strong_inference",
"http.route": "/checkout/confirm",
"security.action": "block",
"raw.reference": "restricted://incident/INC-42/event/991"
}Give DNS its own logic
Do not label every missing record a DNS outage. RFC 2308 distinguishes NXDOMAIN from NODATA; SERVFAIL, timeout, cache state, TTL, and authoritative versus recursive perspective also change the diagnosis. Resolver query logs can omit cache-served repeats, so coverage and freshness belong on the timeline alongside the response code.
Run an impact-first incident workflow
Start from a user journey segmented by hostname, route, region, cache state, and status. Declare early when customer impact is visible or more teams are required. Assign command, operations, communication, and planning ownership; record configuration changes and mitigations on the same UTC timeline; preserve evidence before retention windows expire.
MYO can safely be described as bringing near-real-time, full-fidelity edge logs into cross-vendor dashboards with custom alerts and WAF, bot, and DDoS visibility. It does not make every provider event request-joinable, so incident evidence still needs the confidence model above.
Troubleshooting
Timeline quality checks
- Track telemetry freshness as
observed time - source time, not just dashboard availability. - Restrict raw headers, cookies, tokens, full URLs, and client identifiers; use route templates and allowlists.
- Treat public trace headers as untrusted at the edge and never put personal data in trace context.
- Alert when mappings fail, source volume drops, or exact-correlation coverage collapses.
Related guides
Authoritative references
- OpenTelemetry Logs Data Model
- W3C Trace Context
- Google SRE Book: Managing Incidents
- RFC 2308: Negative Caching of DNS Queries
- Cloudflare Logpush HTTP requests fields
Make cross-provider incidents evidence-led
Optimi helps teams assemble one operational view across edge, security, DNS, and origin signals without hiding source context.
Review your incident visibility