Guides

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.

Published
Updated
Reading time
13 min read
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.

The incident evidence path
  1. Source events

    DNS, edge request, WAF, bot, origin, and configuration signals arrive.

  2. Raw evidence

    Immutable source payloads remain access controlled.

  3. Normalised envelope

    Timestamps, route, outcome, vendor, and identifiers are mapped.

  4. Correlation

    Exact IDs and bounded inferences receive confidence labels.

  5. 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.

ConfidenceEvidenceSafe statement
ExactSame trace ID or namespaced immutable request ID“These events describe the same request.”
Strong inferenceSame provider ID, zone, and service“The WAF decision is linked to this edge request.”
Temporal contextSame hostname and bounded incident window“The DNS failure preceded the edge-error increase.”
AggregateMatching regional trend only“These signals changed together; investigation continues.”
Representative normalised event
{
"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.

Authoritative references

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