Why this matters
Some deploys do not throw errors. They just make checkout feel slower or the docs app sluggish. This workflow 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
You
Did the latest frontend release slow anything down?
Agent
I’ll compare web_vital timing by route and release.
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
query: "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 AGENTRY_PUBLIC_API_KEY auth. Include release and route template.
Variations
- “Only check checkout routes.”
- “Compare Chrome mobile against desktop.”
- “Publish this as a release readiness dashboard.”