CDN incidents are easy to misread because a public symptom can originate in the CDN, an origin, DNS, a certificate authority, a cloud dependency, or the customer’s own configuration. Use primary sources to establish what is known before assigning cause.
This page is a monitoring method and source directory. It is not a live incident feed.
Start with the incident class
| Signal | Check first | Confirm with |
|---|---|---|
| Broad availability drop | Provider status page | Provider incident history and your regional probes |
| New CVE or exploited flaw | Vendor advisory and CISA KEV | Product/version scope and remediation text |
| Elevated 5xx responses | CDN and origin logs | The 5xx ownership and diagnosis guide |
| Certificate failures | CDN certificate state and CA status | TLS handshake logs and affected hostnames |
| Cache or purge anomaly | Cache-status headers and purge operation IDs | The purge verification checklist |
| Suspected attack | WAF, bot, and DDoS event logs | Provider advisory, indicators, and application logs |
Primary status sources
- Akamai service status
- AWS Health Dashboard
- Cloudflare status
- Fastly status
- Google Cloud service health
- Microsoft Azure status
Subscribe to the provider’s official email, RSS, Atom, webhook, or API option where one exists. A third-party aggregator is useful for discovery, but it should not be the sole evidence for impact, cause, or resolution.
Primary vulnerability sources
- CISA Known Exploited Vulnerabilities Catalog prioritizes vulnerabilities with evidence of active exploitation.
- NIST National Vulnerability Database provides CVE records and machine-readable data. Treat severity scores as one input, not a substitute for exposure analysis.
- AWS security bulletins publish AWS-specific notices.
- Cloudflare security advisories publish Cloudflare product notices.
- Microsoft Security Response Center publishes Microsoft advisories and update guidance.
Also monitor the advisory channel for the software actually running at the edge or origin: web server, reverse proxy, TLS library, image processor, edge runtime, and deployment tooling.
Triage workflow
- Record the first observed time in UTC, affected hostnames, regions, networks, status codes, and request IDs.
- Preserve response headers and a small set of failing and successful samples.
- Check the provider status page, but do not wait for it before testing the origin directly through an authorized path.
- Compare multiple networks and regions. A single synthetic location cannot establish global impact.
- For a vulnerability, map the advisory’s affected product and version to the deployed service. Do not infer exposure from a vendor name alone.
- Separate confirmed facts from hypotheses in the incident log.
- Record the mitigation, rollback condition, and evidence that service recovered.
- After closure, retain the provider’s final incident report and update runbooks.
What a useful incident note contains
A concise incident note states the time window, affected user task, scope, evidence, mitigation, recovery signal, and unresolved questions. Avoid copying an advisory headline without explaining whether the site’s deployed configuration was in scope.
For resilience planning, see Multi-CDN architecture patterns and cache consistency across CDNs.