HTTP Error Spike Detector

When a backend starts failing, the first sign is usually a clump of 5xx responses — not one or two, but a burst that rises clearly above the surrounding noise. HTTP Error Spike Detector buckets each line of your access log into a fixed time window you choose, counts the 5xx responses that land in every bucket, and flags any bucket that blows past your absolute count threshold, your error-rate threshold, or both at once.

Every parseable line is assigned to a bucket keyed by its timestamp rounded down to the bucket boundary, so a 1-minute bucket for 14:03:47 always covers 14:03:00 through 14:03:59, regardless of how many lines land in it. The status-code pattern targets the code that sits right after the closing quote of the request line, which is how Apache and Nginx combined/common log formats write it, so a coincidental "500" sitting in an unrelated field elsewhere on the line — a bytes-sent count, a response time, a random query parameter — is not mistaken for a backend error. Only genuine 5xx status codes at that position are counted; 4xx client errors are deliberately excluded so a wave of bad requests or bot traffic does not drown out real backend faults.

Every flagged bucket comes back with its start time, its exact error count out of total requests in that bucket, the error ratio as a percentage, and the top endpoints and source IPs driving it, so you can go from "something spiked" to "this URI, from these IPs" without leaving the tool. Lines with unparseable timestamps are tracked separately in the scanned/error/bucket stats so you always know how much of the file the analysis actually covered.

• Time-bucket spike detection — choose windows from 30 seconds up to 1 hour depending on how fine-grained you need the burst to be.
• Absolute and ratio thresholds — flag on a minimum 5xx count, a minimum error percentage, or require both together.
• Position-aware 5xx matching — the default pattern matches the status code after the closing request quote, avoiding false hits from unrelated numeric fields.
• 5xx-focused — 4xx client-error noise is excluded from both the count and the ratio.
• Top endpoints and IPs per spike — the four most frequent URIs and source IPs inside each flagged bucket.
• Full bucket timeline — every window is listed, not just the flagged ones, with flagged buckets marked so you can see the shape of the whole session.
• Coverage counter — lines scanned, 5xx found, and buckets built are all reported so you know how complete the analysis is.
• Local only — nothing is uploaded, everything runs in your browser.

1. Paste your access log — Apache, Nginx, or reverse-proxy format all work as long as a timestamp and a status code are present on each line.
2. Check the timestamp and status-code patterns and adjust them if your log format differs from the common/combined default.
3. Choose the bucket window — shorter windows (30s, 1min) catch fast, sharp bursts; longer windows (15min, 1h) smooth out noise and highlight sustained degradation.
4. Set the thresholds — a minimum 5xx count, a minimum error ratio, or both; set the ratio to 0 to rely on count alone.
5. Detect spikes. Flagged buckets appear with error counts, ratios, top endpoints, and top IPs.
6. Drill into the timeline to confirm a flagged bucket is a real burst against the surrounding baseline, not an isolated blip.

Example 1 — Dying database. At 14:00 an endpoint stops returning rows and the access log shows 200-level requests collapsing to 500 in the same minute; with a 1-minute bucket and a 25% ratio threshold, that minute trips the ratio threshold even if the absolute count is small.

Example 2 — Deployment burn. Post-deploy, 503s cluster for five minutes before health checks pass. A 5-minute bucket window flags that single window and names the failing URI in its top-endpoints breakdown, pointing straight at the bad release.

Example 3 — Scrapers hitting empty cache. A scraper storms a cold-cache path and 502s jump to 40% of its traffic in a short window; the per-IP breakdown inside the flagged bucket points directly at the scraper“s source address.

Example 4 — Byte-count false positive, avoided. A line ends with a 200 status and a bytes-sent field of 500. With the default position-aware pattern, that "500" is never counted as an error because it does not sit immediately after the closing request quote — only the real status field does.

• Burst-aware — flags genuine spikes against a window baseline instead of reacting to any single error.
• Ratio + absolute — quiet, low-traffic hours stay quiet, since a handful of errors on near-zero traffic will not trip a ratio-only rule unless you want it to.
• Accurate matching — the default status pattern targets the actual status-code field, avoiding false positives from coincidental numbers elsewhere on the line.
• Root-cause context — top URI and top IP per spike take you from alarm straight to a plausible cause.
• Global timeline — see every bucket for the whole session at once, flagged or not, to judge whether a spike is isolated or part of a trend.
• Private — all processing happens client-side, nothing is sent anywhere.