Outage or attack? How to tell in the first hour

Treat every large outage as unexplained for the first hour. In 2025, AWS and Cloudflare both published post-incident accounts that rule out an attack, and the Iberian blackout panel found no cyber cause. Look at what changed, where the failure started, and whether data or access was touched.

Three real examples

AWS says its October 2025 us-east-1 disruption came from a race condition in DynamoDB's DNS automation. Cloudflare says its 5 December 2025 outage was not caused, directly or indirectly, by a cyber attack, and traced it to a configuration change and a latent code bug. ENTSO-E's panel on the April 2025 Iberian blackout lists many interacting grid factors and does not mention a cyber cause.

Each one looked, in the first hours, like something that could have been hostile. Each turned out to be a failure.

Questions to ask first

1. What changed in the last day? Deployments, configuration pushes, certificate renewals and automation runs cause most failures. Cloudflare's trigger was a change pushed within seconds.
2. Is the failure shaped like a change? A sudden global step at one timestamp points to a push. A gradual spread through accounts points to an intruder.
3. Did anything unexpected get touched? New admin accounts, unusual logins, disabled logging and data leaving the network point toward an attack.
4. Are other organisations seeing the same thing? Provider status pages and sector contacts answer this fast.
5. Is there a message, ransom note or encrypted file? That settles it.

Run both tracks for an hour

You cannot afford to guess wrong. Keep a recovery track going, restoring service, and a containment track, preserving logs and limiting access. Most of the work is the same. The one thing you avoid is wiping evidence.

What to preserve

1. Logs from identity, network edge and deployment systems.
2. A list of recent changes with who made them.
3. Memory or disk images if you suspect compromise, before rebuilding.
4. Notes on every action you take and when.

What to say publicly

State what you know and what you do not. Do not say "no evidence of an attack" in a way that sounds like "there was no attack". Say what you checked. If you later change the scope, say so plainly.

Make the answer faster next time

1. Keep a change log that on-call staff can read in seconds.
2. Alert on privileged actions and new accounts, so absence of them means something.
3. Write a one page decision tree like the list above.
4. Practise it as a tabletop with a scenario that is not an attack.

For the details of two of these events, see the AWS outage post and the Cloudflare December outage post.

Where Safeguard fits

Safeguard's audit and evidence automation can help keep records of changes and decisions during review. It does not detect network intrusion. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• AWS post-event summary, 19 to 20 October 2025
• Cloudflare, outage on December 5, 2025
• ENTSO-E, Iberian blackout expert panel page

Last reviewed: 19 October 2026.