Features · Monitoring · Slow-Request Log
Monitoring · Slow-Request Log

Every request that took too long,
with the query that did it.

A Laravel middleware that records every HTTP request above a configurable threshold (default 2 s). Route, status, duration, peak memory, query count + the top-3 parameterised SQL queries that ran inside it. The retroactive log the platform self-monitors with.

requests over 2s · last hour
4.82s POST /checkout #1041
3.11s GET /reports/monthly #1042
2.44s GET /servers?page=4 #1043
top query SELECT * FROM orders … 3.9s
n+1 detected · 214 queries
— Why this matters

Server metrics stay flat while your users wait.

01

Slow is measured at the request, not the host.

CPU at 19% and a four-second checkout are entirely compatible. Only the request knows.

02

The query is usually the answer.

Each slow request carries its top SQL queries, so "why" is on the same page as "what".

03

Aggregate by route or you will chase individuals.

One slow request is an anecdote. A route with a 3-second average is a bug.

— What's included

What is recorded and where you read it.

Everything over the threshold
Default two seconds, configurable.
Per request
Method, path, route name, status, duration and peak memory.
Top SQL queries
Attached to the request that ran them.
Recent tab
Paginated and filterable by minimum duration.
By-route tab
Hits with average, max and min duration, and when it last happened.
Detail view
KPI strip, full request meta, and each slow query in context.
30-day retention
Cleaned up nightly.
We run it on ourselves
Which is how platform slowness gets caught before you report it.
— What it looks like

p95 request time, by route.

1.4 s 2 s threshold
Example view · POST /checkout · last 6 h · threshold 2 s
— How it works

Measured where the user waits.

1

Time the request

Anything over your threshold is recorded with its route, method, duration and status.

2

Attribute the queries

The slowest SQL statements for that request are captured with it, which is usually where the answer already is.

3

Aggregate by route

Individual slow requests are noise. Grouping by route is what shows you the one endpoint worth fixing.

— Works with

Connected capabilities

— FAQ

Questions, answered honestly.

How much overhead does it add? +
Sub-millisecond per request. One microtime() at start, a query listener that fires only when a query executes, one insert per slow request (and only above threshold).
Are SQL bind values stored? +
No. Queries are captured with ? placeholders intact — values never persist. The parameterised SQL is what aggregates well anyway.
What's the default threshold? +
2 s. Configurable via HOSTATLAS_SLOW_REQUEST_MS in .env. Production setups often run higher (5 s) to surface only true outliers.
Excluded paths? +
The healthcheck (/up), Vite asset paths and the debugger view to avoid a feedback loop on the table itself.

Catch slow before users do.

Slow-Request Log is included from Starter. The platform uses the same middleware on itself.

Get early access Back to Monitoring