---
title: "Build a Unified Incident Timeline Across CDN, WAF, DNS and Origin"
description: "Correlate CDN, WAF, DNS, bot, DDoS, and origin evidence into a defensible incident timeline with provenance, confidence labels, privacy controls, and an SRE workflow."
canonical_url: https://optimi.com/en/guides/unified-incident-timeline-cdn-waf-dns-origin
md_url: https://optimi.com/en/guides/unified-incident-timeline-cdn-waf-dns-origin.md
last_updated: 2026-07-15
---

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

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.

## 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.*

**A unified timeline keeps evidence confidence explicit**

![Flowchart showing DNS, CDN, WAF, origin, and configuration-change events preserved as access-controlled raw evidence, mapped to a normalised envelope, then connected to an incident timeline as exact, strong-inference, or temporal-context relationships.](/diagrams/unified-incident-timeline-cdn-waf-dns-origin/evidence-confidence.svg)

*Preserving provenance before correlation lets operators combine provider evidence without presenting an inference as proven causality.*

## 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.” |

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

## 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

- [Website Security Incident Response Plan](/en/guides/website-security-incident-response)
- [Kubernetes Observability](/en/guides/kubernetes-observability)
- [Global Edge Architecture](/en/guides/global-edge-architecture)

## Authoritative references

- [OpenTelemetry Logs Data Model](https://opentelemetry.io/docs/specs/otel/logs/data-model/)
- [W3C Trace Context](https://www.w3.org/TR/trace-context/)
- [Google SRE Book: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [RFC 2308: Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308.html)
- [Cloudflare Logpush HTTP requests fields](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/zone/http_requests/)

[Review your incident visibility](/en/contact): Make cross-provider incidents evidence-led — Optimi helps teams assemble one operational view across edge, security, DNS, and origin signals without hiding source context.