API: access-log analytics
Optional plugin. Enable per application in Settings → Plugins; access-analytics 404s while disabled. When enabled, an Access logs view appears in the sidebar. See Access-log analytics for how the aggregation works and what it can't tell you (no latency).
GET /?api=access-analytics&days={n}
days bounds the window, 1–90, default 7.
{
"window_days": 7,
"total": 128430,
"unique_paths": 342,
"error_rate": 0.06,
"status_classes": [{"class":"2xx","count":105312}, {"class":"5xx","count":412}],
"by_day": [{"day":"2026-08-14","count":18010,"errors":90}],
"top_paths": [{"path":"/api/checkout","count":18204,"errors":208}],
"error_paths": [{"path":"/login","errors":140}],
"methods": [{"method":"GET","count":101220}],
"top_agents": [{"agent":"curl/8.4.0","count":8204}]
}
error_rate is the 4xx+5xx share of requests over the window. All aggregates read fields already parsed onto each nginx-access occurrence (method, path, status, user agent) — nothing is re-ingested for this view.
Related
- Access-log analytics
- Nginx access parsing — where these fields come from