Map what must stay available
List public websites, APIs, DNS dependencies and services that users need to complete a journey. Record the host, protection provider and escalation contact for each. A protected homepage is not enough if an essential API is outside the protection path.
Agree on a minimum service level during an incident. Your priority might be preserving sign-in and existing orders while temporarily limiting expensive optional features.
Review the edge and origin together
Confirm which hostnames and protocols your protection service actually covers. If an origin is intended to receive traffic only through a reverse proxy, review its access policy with the provider and preserve the management paths you need for recovery.
Keep a tested rollback path before changing access rules. A configuration that blocks health checks or necessary provider traffic can cause an outage of its own.
Put limits around expensive work
Review application timeouts, request sizes, pagination, queue capacity and expensive operations. Resource limits should reflect legitimate usage and should be evaluated against normal traffic before enforcement.
A single per-IP limit may affect many real users behind a shared connection. Where the application supports it, consider the user, account or operation as additional context.
- Measure the normal behavior of important endpoints.
- Check that rejected work fails predictably rather than hanging.
- Monitor both blocked activity and successful user journeys.
Exercise the response plan
Walk through who declares an incident, who contacts the provider and who can change policy. Keep a status channel outside the main application. Validate defensive changes with a bounded, authorized test and record what the exercise did not cover. No single successful run proves protection against every future incident.