Error / Retry Analyzer

Failures hide the real story: does the client retry, and does it succeed? Error / Retry Analyzer groups attempts by client and endpoint, then tells you which failures were retried and whether the retry recovered.

Resilience is not “did it 500” — it is “how did the next request go”. A single 500 might be a blip your client silently retried past; three 500s in a row on the same endpoint with no successful follow-up is a real outage. This tool tells the two apart automatically.

Grouping defaults to client IP plus HTTP method and path — good enough for most access logs. If your logs carry a request-ID or correlation-ID header, supply that header name and the analyzer groups by ID instead, which is far more precise when multiple clients share an IP (behind a NAT or a shared gateway) or when a single client legitimately makes many unrelated requests to the same endpoint.

• Retry sequences — attempts grouped by client IP + method + path, or by a request-ID header you specify.
• Recovery flag — each sequence is marked recovered if its last attempt was a 2xx/3xx, or unresolved if it ended on a failure.
• Status breakdown — every failure code (400 and above) tallied separately, so 404 noise doesn’t hide a 500 spike.
• Optional ID header — point it at X-Request-ID, X-Correlation-ID, or any header your logs carry for precise correlation.
• Auto-sorted — attempts within a sequence are ordered by timestamp automatically; you don’t need to pre-sort the paste.
• Sequence ranking — sequences are listed longest-first, so the retry storms with the most attempts surface at the top.

1. Paste access log lines with the timestamp first, in the form YYYY-MM-DD HH:MM:SS <client> <METHOD> <path> <status>.
2. Optionally enter a request-ID header name (e.g. X-Request-ID) if your logs embed one — grouping switches from IP+endpoint to ID+endpoint automatically.
3. Analyze. The tool groups attempts into sequences, flags which ones include a failure, and marks whether the final attempt in each sequence recovered.
4. Scan the failures-by-status list to see whether the problem is widespread 404s or a concentrated run of 5xx errors.
5. Copy the full report — stats, sequences and status breakdown — for an incident writeup.

Example 1 — Payment 503. A retry storm on POST /api/pay from one client shows up as a single sequence with three attempts — and “unresolved”, meaning even the last retry failed. That’s worth paging someone about.

Example 2 — Idempotency proof. The same order ID, correlated via a request-ID header, appears as a sequence that ends in a 2xx — proof your retry-safe endpoint absorbed a transient failure without the client-facing operation failing.

Example 3 — 404 noise. A one-off 404 never forms a sequence (sequences need 2+ attempts with the same key), so scanner probes and broken links don’t clutter the retry report; only genuinely repeated misses on the same endpoint stand out.

Example 4 — Retry-safe rollout. After adding retry logic to a flaky downstream call, re-run the analyzer on the next day’s logs and check that the recovered count for that endpoint’s sequences went up.

• See the retry, not just the error — a lone failure and a failure-then-recovery tell very different stories about system health.
• Recovery signal — instantly separates “self-healed” sequences from ones that are still stuck.
• ID-aware — correlate by request ID when IP-based grouping would be too coarse.
• Status-code clarity — a breakdown by code separates harmless 404 noise from serious 5xx spikes.
• Private — all analysis runs in your browser; access logs are never uploaded.