Why this matters
Some deploys do not throw errors. They just make checkout feel slower or the docs app sluggish. This recipe catches those regressions as product-impacting incidents.
What you get
- Routes whose p75 or p95 performance regressed
- Browser and release segments
- A short list of likely product surfaces affected
- Follow-up queries for specific pages
Walk through it
Did the latest frontend release slow anything down?
I’ll compare web_vital timing by route and release.
POST /v1/projects/:project_id/analytics/query {
project_id: "default",
hogql: "SELECT properties.route AS route, properties.metric AS metric, properties.release AS release, properties.browser AS browser, quantile(0.75)(toFloat(properties.value_ms)) AS p75_ms, quantile(0.95)(toFloat(properties.value_ms)) AS p95_ms, count() AS samples FROM events WHERE event = 'web_vital' AND timestamp > now() - INTERVAL 7 DAY GROUP BY route, metric, release, browser ORDER BY p95_ms DESC LIMIT 50"
}
The output
The agent returns the routes and browser segments that worsened, with enough sample size to be credible. It should call out low-sample rows instead of overclaiming.
Setting it up
Post web-vital or page timing events from the browser with DSN auth. Include release and route template.
Variations
- “Only check checkout routes.”
- “Compare Chrome mobile against desktop.”
- “Publish this as a release readiness dashboard.”