On this page
Repeat the user journey that failed
A traffic graph returning to normal does not demonstrate service recovery. Repeat login, resource loading or a game connection from affected networks and from an unaffected reference network. Test new connections separately from established sessions: a temporary filter can treat them differently. Record times and measurement locations so results can be compared with network changes.
Retire emergency controls deliberately
Inventory blackhole announcements, FlowSpec rules, ACLs and rate limits introduced during the incident. Assign an owner and a withdrawal condition to each. Remove restrictions in stages while watching both counters and application probes. If traffic returns, this sequence helps identify the useful control without restoring every restriction indiscriminately.
Keep an actionable incident record
Preserve affected prefixes, time windows, packet rates, bandwidth measurements and routing changes. Separate observations from hypotheses; a traffic spike alone does not establish why a service failed. Turn the review into assigned actions such as correcting a threshold, adding a probe or clarifying provider escalation. This article covers recovery; the emergency guide covers the first response.
