Short DDoS bursts: a practical first-fifteen-minutes runbook

Prepare for the incident that finishes before the meeting starts

Cloudflare's third-quarter 2026 DDoS report, published on 29 October, describes an operationally important pattern: in its network-layer dataset, 96% of attacks lasted less than ten minutes and 98% remained below one gigabit per second. These are observations from one provider's protected network, rather than a census of every Internet attack. They nevertheless suggest a useful question for a small infrastructure team: can you identify the affected service, preserve evidence and choose an appropriate response while a short burst is still happening? A procedure that begins with finding the right dashboard password can easily outlast the entire event.

The runbook below is our operational interpretation, not another set of measurements from that report. It is designed for an operator responsible for an ordinary public application and its servers. The goal is to keep useful work available and explain any intervention. A short outage still matters when it interrupts a payment, classroom session or customer integration. Equally, a brief spike is not automatically malicious. A launch, cache refill or broken client can create similar pressure. Your first job is to identify the failing resource and the evidence available, so that the response addresses the real bottleneck rather than the most dramatic chart.

Minute zero: name the affected outcome and destination

Begin with one sentence describing what users cannot do. For example, the catalogue opens but search requests time out, or the entire origin is unreachable from two independent networks. Name the public hostname, important path, expected application and server. If the product contains several components, identify which one serves that flow. A web frontend, assistant endpoint and background worker may share a product name while running as distinct processes. Read the current placement inventory rather than relying on the server remembered from the last release. Preserve its observation time, especially if migration, scaling or a recent deployment could have changed the destination.

Choose a harmless representative check and record its result beside the time. A successful static homepage cannot establish that a slow authenticated operation works. A local health endpoint cannot establish that public DNS and TLS reach the intended service. Use a combination that tests the important boundary without adding substantial load: one public request, the configured local health check and current host evidence may be enough initially. If a client is using a proxy or an old resolver cache, note that route. The useful starting record is a concrete failure at a named destination, not an unqualified statement that the Internet is attacking us.

Separate bandwidth, packets and application work

Three different limits can make a service unavailable. The incoming network path can saturate before traffic reaches the host. The host or network stack can struggle with packet or connection processing. The application can exhaust workers, database connections or expensive computation even while bandwidth remains modest. Measure the layer you are trying to explain. Bits per second, packets per second, connections and HTTP requests per second are different quantities. A provider's traffic graph, interface counters and application request counters describe different parts of the path. A large number in one unit does not identify which limit your users are experiencing.

Record the server's actual operating allowance, not only the nominal capacity advertised for its network interface. A small instance can sit behind a provider policy or shared upstream bottleneck. Conversely, a database-backed endpoint can fail under a request rate that a cached page handles comfortably. If the upstream link is already saturated, a local HTTP rule cannot recover the bandwidth consumed before the packet arrives. Escalation to the network provider or a suitable upstream protection service belongs in that branch of the runbook. Host-level controls remain useful where the host still receives enough traffic and management access to act, but the boundary must remain visible.

Minute two: capture a synchronized evidence window

Select one incident window and use it across host, traffic and application views. Compare incoming traffic, successful user responses, upstream latency, errors and resource pressure during the same interval. A screenshot from one minute and a log extract from another can support a convincing but incorrect causal story. Capture the window start and end, server identity, important route and collection freshness. Include the last known normal interval where available. This makes later comparison possible even if the burst ends quickly or the live request buffer overwrites the interesting rows before the incident discussion begins.

Short bursts can disappear inside long averages. Consider an explicitly hypothetical minute containing five seconds at sixty thousand requests per second and fifty-five seconds at one thousand. The minute average is about 5,917 requests per second, despite the much larger brief peak. This calculation illustrates aggregation, not an observed Hostwatch attack. Inspect the finest reliable resolution your collection actually retains, and keep the bucket width beside the value. If only minute totals exist, do not reconstruct a precise five-second peak from them. Preserve what was measured and the limitation that prevents a stronger conclusion.

Distinguish complete counters from retained examples

A bounded request list answers different questions from a full-window counter. Counters can establish scale and timing, while retained rows can reveal path shapes, user-agent claims and particular failures. The latest examples may overrepresent the last phase of an incident. Missing rows do not prove that an earlier pattern never occurred. In Hostwatch, keep recorded totals, retained request coverage and observation timestamps visible when moving between traffic and service views. This is especially important during a fast incident, when a small list of striking failures can look more comprehensive than the underlying retention permits.

Save only the evidence required to explain the decision, under the team's access and retention policy. Raw queries and headers can contain private information. Prefer normalized routes, relevant status counts and redacted examples over an indiscriminate log dump. Preserve the rule generation or operation receipt if a control is changed. A useful incident record separates direct observations from inference: the search route became expensive is an observation supported by timings; a coordinated malicious query pattern is a hypothesis requiring more evidence. Maintaining that distinction helps the next operator improve the response without inheriting an unsupported attack label.

Minute five: ask whether the workload could be legitimate

Check the recent change timeline. A deployment can invalidate caches, a client release can introduce a retry loop, and a successful announcement can create a genuine surge. Compare route diversity, session continuity, miss rates and the cost of individual requests. Repeated User-Agent strings or a same-site Referer do not establish who controls the caller. A bot name in a header is a claim. A shared network address can represent many unrelated users. Preserve the difference between observed network origin, a verified service identity and an application's trusted account information before making exceptions or applying a restrictive policy.

A practical comparison is to follow one ordinary flow through the same window. Can a known test client load the page, obtain its required resources and finish the important action? Does the slow route create database work before the HTTP timeout, and do cancelled callers leave that work running? Look for signs of an internal amplification loop, such as rising downstream attempts without a proportional increase in genuine user arrivals. These checks need not delay an urgent narrow protection. They make its scope better informed and reduce the chance that a response aimed at an attacker instead blocks the customers whose retries are amplifying an application defect.

Choose the smallest response that fits the failing layer

For an overloaded application route, consider a temporary route-specific limit, bounded admission or a controlled degradation that avoids the expensive work. For repeated public reads, a reviewed cache policy can reduce origin cost. For a broken client, controlling retries may be more effective than blocking addresses. For a network-capacity event, contact the upstream provider with the affected addresses, time window and measured unit. Avoid treating these as interchangeable tools. A broader deny policy can make a chart quieter without restoring the user flow, while a perfectly configured application limit cannot remove a saturated upstream path.

Before applying, name the exact site, route, permitted action, duration and recovery condition. Use a fresh preview where the system supplies one. In Hostwatch, supported changes use configured capabilities and governance; an assistant's ability to read evidence does not grant general authority to run shell commands or change arbitrary network policy. Keep an immediate reversal path available. When urgency requires a first action before the diagnosis is complete, make that action bounded enough to inspect and explain. The result should buy useful operating room while preserving evidence, rather than turn a tentative hypothesis into a permanent rule across the entire service.

Minute eight: verify the installed action, then its effect

First establish whether the intended control is actually installed. Check the rule identity, target, generation and expiry where available. Then compare the important user outcome and host pressure after application. An observed 429 is an HTTP outcome, not proof that a particular new rate limit matched it. A timeout is not a successful block. If action counters exist, keep them beside the response evidence. If the system cannot connect a response to a verified rule, state that attribution is unavailable. This prevents an overloaded application from being misreported as a working defensive control simply because more requests now fail.

Use a short, consistent verification sequence: the important public route, the configured health endpoint, current resource evidence and a check of affected client cohorts. A route-specific improvement can coexist with a failing sibling component or a growing backlog elsewhere. If genuine users lose access, narrow or reverse the action and preserve that result as part of the incident. A successful rollback is a recovery outcome; it does not make the attempted policy correct. Report what improved, what remained unhealthy and which conclusions still depend on incomplete retention. This allows another operator to assess the next step without repeating the same uncertain investigation.

Escalate with an evidence packet the provider can use

An upstream escalation should be compact enough to act on quickly. Include the customer or service reference, affected public destination, UTC interval, observed bandwidth or packet rate, connection symptoms and whether management access survives. Distinguish provider-edge measurements from host-side measurements. If you have flow information or a relevant packet sample collected through an authorized process, describe its scope and handling. Do not substitute a list of suspected countries for the traffic facts the provider needs. A precise statement that the ingress path is saturated is more actionable than a confident attack-family label unsupported by the available evidence.

Keep out-of-band contact and recovery access prepared before an incident. The contact path should not depend entirely on the application or the same congested connection. Know which network controls the provider can offer and which changes require the account owner's authorization. Escalation can run alongside a narrow local response while the host remains reachable. Continue measuring the real user outcome after an upstream change, because clean interface graphs alone do not prove that an origin pool, database or cache has recovered. The provider and application operator own different layers of the same restoration effort, so their observations need to be joined through a common interval and destination.

Do not let incident response become a second overload

Repeated broad log searches, filesystem scans and diagnostic requests can compete with an already stressed application. Prefer existing counters and small, scoped reads first. Capture a bounded sample rather than requesting every retained record repeatedly. Coordinate operators so two people do not unknowingly apply competing rules. Keep one durable operation key for a true retry of an infrastructure action, and inspect its recorded state after a lost response. An unknown outcome needs reconciliation with the actual runtime or policy state before another change is issued. Otherwise an acknowledgment failure can become duplicate work during the busiest part of the incident.

The same discipline applies to software changes proposed during response. A staged image or accepted build is not a serving fix. If a release is necessary, follow the component's explicit application and health verification process, with attention to data compatibility. Do not add a Git-triggered deployment path in the middle of an incident merely to make a command shorter. Hostwatch releases remain deliberate operations, while existing certificate and backup maintenance have separate purposes. The operating goal is to reduce uncertainty and recover capacity. A large number of simultaneous changes can make it impossible to determine which one helped or how to reverse the one that harmed ordinary users.

Minute fifteen: preserve a useful ending, even if the burst stopped

If pressure has ended, inspect the user flow, backlog and resource state before declaring recovery. A completed attack can leave exhausted connections, delayed jobs or a full logging volume behind it. Review temporary policy expiry and remove or let expire controls that no longer have a justified purpose. Keep the incident window, relevant examples, verified actions and outcome in one record. Include false positives and collection gaps. A short event with a clear recovery explanation produces a better operational improvement than a dramatic screenshot followed by an unexplained claim that the protection system solved everything.

Turn the incident into one concrete next step: a tighter route-cost budget, verified caller exception, retry correction, cache policy, better upstream contact path or more appropriate collection cadence. Assign an owner and a way to verify the improvement. The report that motivated this runbook concerns one provider's observations; the decisions here must be tested against your own service and constraints. The useful lesson is operational readiness for brief pressure, with a known destination and a small set of trustworthy checks. The next incident should start with those facts already available, leaving the operator free to restore useful service rather than reconstruct the infrastructure under stress.

• Record the affected user outcome, hostname, component and placement timestamp.
• Separate network capacity, packet pressure and application work.
• Preserve a synchronized window and label retained request coverage.
• Record the exact action, expiry, installed state and rollback condition.
• Verify legitimate workflows, recovery and any remaining unknowns.