HTTP Access Latency Log Analyzer
Analyze NGINX, Apache, or ALB access logs locally for endpoint P95 and 5xx rates with clear parse-gap evidence and SLA findings.{{ summaryTitle }}
| Endpoint | Requests | P50 | P95 | P99 | 5xx | Slow | State | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.endpoint }} | {{ row.requests }} | {{ formatMs(row.p50_ms) }} | {{ formatMs(row.p95_ms) }} | {{ formatMs(row.p99_ms) }} | {{ formatPercent(row.error_rate_pct) }} | {{ row.slow_count }} | {{ stateLabel(row.state) }} |
| Priority | Finding | Evidence | Suggested next step | Copy |
|---|---|---|---|---|
| {{ row.priority }} | {{ row.finding }} | {{ row.evidence }} | {{ row.next_step }} |
| Line | Parser | Method | Endpoint | Status | Latency ms | Timing basis | Parsed | Note | Copy |
|---|---|---|---|---|---|---|---|---|---|
| {{ row.line }} | {{ row.parser }} | {{ row.method }} | {{ row.endpoint }} | {{ row.status }} | {{ row.latency_ms }} | {{ row.basis }} | {{ row.parsed }} | {{ row.note }} |
{{ chartError }}
A web request can spend time at the client edge, inside a load balancer, waiting for an application, or receiving the response. An access log measures only the stages included in its configured timing fields. A 400 ms backend measurement and a 400 ms total-request measurement describe different observation points even though the numbers look identical.
Latency analysis becomes useful when requests are grouped into comparable endpoints and read as a distribution. The median, or P50, describes the middle request. P95 and P99 expose progressively slower parts of the sample. Those percentiles are usually more informative than one maximum, but a small or unrepresentative log slice can still make them unstable.
| Perspective | Typical field | What it includes |
|---|---|---|
| NGINX backend | upstream_response_time |
Time spent receiving the response from an upstream server. |
| NGINX request total | request_time |
Time from reading the first request bytes through writing the request log. |
| Apache request duration | %D, %T, or %{UNIT}T |
Request-serving duration in the configured unit. |
| Application Load Balancer | Request, target, and response processing times | Separate load-balancer stages that can be read individually or summed. |
Endpoint grouping prevents IDs from splitting one route into hundreds of tiny samples. It also removes query strings so searches and request parameters do not create separate groups. That normalization is helpful for route-level latency, but it can hide meaningful differences when one customer, object size, query parameter, or endpoint variant is genuinely slower.
Server errors add another dimension. A low P95 does not compensate for a high 5xx rate, and a clean 5xx rate does not prove users avoided redirects, 4xx responses, client disconnects, or application-level errors returned with status 200. Access-log review should be paired with traces, application logs, metrics, and a clear service objective.
The most consequential mistake is comparing unlike samples. Keep the parser, latency basis, path-grouping rule, observation point, traffic mix, and time window consistent before calling a change faster or slower.
How to Use This Tool:
Choose the timing perspective before comparing percentiles. Backend and total-request latency answer different questions.
- Enter a Service name and choose the Latency basis. Auto uses backend or target timing when available and falls back to request-total timing.
- Set the P95 target from 1 to 60,000 ms and the 5xx target from 0% to 100%.
- Choose whether to Group dynamic paths. Keep it on for route-level analysis; turn it off when each literal path is meaningful.
- Select the source format or leave Source format on Auto detect, then paste or load up to 10,000 nonblank log lines. Pin the parser when a custom first line is ambiguous.
- Use Slow cutoff override only when the service has a known threshold. A value of 0 derives the cutoff as the larger of 1,000 ms and the P95 target.
- Review ignored rows before trusting the distribution, then compare Endpoint ledger with SLA findings. Recheck the top endpoints in traces or backend logs.
Interpreting Results:
An endpoint fails when its 5xx rate is greater than the configured target. Otherwise it needs review when P95 is greater than its target or at least one request is at or above the effective slow cutoff. Equality does not breach the P95 or 5xx target, while equality does count as slow.
Ignored lines shrink the denominator for both percentiles and the 5xx rate. A low error rate is not trustworthy when many failed rows could not be parsed. Check the evidence rows, resolved parser, timing basis, and request count before treating a state as representative.
P99 is a tail clue, not a diagnosis. A slow route may reflect application work, upstream queues, retries, network transfer, client upload time, or a unit mismatch in the source format. Verify the observation point before assigning ownership.
Technical Details:
Each accepted row must produce an endpoint and a non-negative latency. Auto-detection examines only the first nonblank row. NGINX timing values are read in seconds and converted to milliseconds; when a field contains several upstream timings separated by commas, semicolons, or colons, the largest non-negative value is used. Application Load Balancer target time is the backend measure, while its edge measure is the sum of non-negative request, target, and response processing times.
Transformation Core:
| Stage | Transformation |
|---|---|
| Parse | Read method, path, status, and timing with the selected NGINX, Apache, or ALB rule. |
| Choose timing | Use requested backend or edge timing, with the documented fallback when that field is absent. |
| Normalize route | Remove query text; when grouping is enabled, replace numeric path segments with :id and hexadecimal segments of at least eight characters with :hash. |
| Group | Collect parsed rows by HTTP method plus normalized path. |
| Measure | Compute P50, P95, P99, 5xx rate, and slow-request count for each group and the whole sample. |
Apache duration tokens need an explicit unit whenever possible. A suffix of us is divided by 1,000, ms is retained, and s is multiplied by 1,000. A bare value above 10,000 is treated as microseconds; a bare decimal no greater than 60 is treated as seconds; other bare values are treated as milliseconds. Pinning a well-defined custom log format is safer than relying on those heuristics.
Formula Core:
Percentiles use linear interpolation between adjacent sorted samples. The 5xx percentage uses only successfully parsed requests.
x is the latency list sorted in ascending order, n is its length, p is 50, 95, or 99, and lo and hi are the floor and ceiling of rank r. With one sample, every percentile equals that sample.
Source text is limited to 2 MiB and 10,000 nonblank lines. The parse evidence limit controls only how many evidence rows are shown, not how many accepted requests enter the calculations.
Privacy and Limitations:
Log text is processed in the browser and excluded from page URL state. Access logs can contain client addresses, account or object IDs, query parameters, internal hosts, user agents, and request paths, so local processing does not remove the need to redact exports.
- The analyzer does not reconstruct missing timing fields, deduplicate requests, or weight endpoints by production traffic outside the supplied slice.
- Auto-detection can choose the wrong parser from an unusual first line.
- Path grouping can merge requests whose IDs or hashes correlate with different workloads.
- The configured P95 and 5xx targets are local review gates, not proof of an SLA breach without the correct contractual window and exclusions.
References:
- NGINX HTTP log module, NGINX.
- NGINX HTTP upstream module, NGINX.
- Apache mod_log_config documentation, Apache Software Foundation.
- Application Load Balancer access logs, Amazon Web Services.
- How to configure detailed Apache logging, Simplified Guide.