Home › Access-Log Triage
Access-log triage: which routes are failing, and how often
Direct answer: drop an Nginx/Apache access log below. You get the status distribution, the busiest hours, and — the part that matters — error paths grouped with numeric IDs masked, so every repeat of a failing route counts toward the same problem. Processed locally; nothing is uploaded.
Triage this access log
Error paths, grouped (IDs masked)
| Path pattern | Errors | Total hits | Statuses |
|---|
Status distribution
| Status | Responses |
|---|
Top paths
| Path pattern | Hits |
|---|
Busiest hours
How to read the results
Error paths first. One pattern with a large error count points at a specific route — a bad deploy, a deleted product range, a misconfigured rewrite. Many patterns with small counts each point at something systemic: a scanner working through a wordlist, or a sitemap full of dead URLs. The shape of the table is the diagnosis starting point; the guide finding errors in an Nginx access log walks through both shapes.
Then the clock. Busiest hours plus the status mix tell you whether an error burst lines up with a traffic peak (capacity), a deploy (check the release time), or a crawler run — and if crawlers are the question, the SEO Bot-Log Checker answers it from the same file. For application errors (stack traces, exceptions), switch to the Error Grouper.
Frequently asked questions
Which access-log formats are supported?
Nginx and Apache combined format (with referer and user-agent) and common format (without them). Custom formats with reordered or extra fields may parse partially — unparsed lines are counted and reported, never silently dropped.
Why group error paths with IDs masked?
Because /products/123 returning 404 and /products/456 returning 404 are usually the same problem — a route pattern failing — while the raw log makes them look like hundreds of unrelated lines. Masking numeric, UUID and long-ID path segments groups repeats on the same route so the failing routes rank by count.
What should I look at first in the results?
The error-path table, sorted by error count: it separates "one broken route" (one pattern, many errors) from "the whole site is down" (many patterns, similar counts). Then the status distribution: a 5xx spike is an application problem; a 4xx spike is often a bad link, a scanner, or a deploy that removed pages.
Can this tell me which visitors were bots?
That is the sister tool: the SEO Bot-Log Checker reads the same file and reports crawler visits by user-agent. This page stays focused on requests, statuses and error paths.