Skip to content
Telemetry
For web teams connecting Core Web Vitals to routes and releases

Frontend performance monitoring with SQL

Track typed LCP, INP, and CLS samples by stable route and release, then use SQL to find frontend regressions without collecting raw URLs or page content.

Reviewed by the Telemetry product team on . We checked the event fields, suggested queries, and data to exclude. Who reviews this page

Why this works
  • Track LCP, INP, and CLS separately, with the correct unit for each metric.
  • Tie performance changes to stable route templates, release identifiers, and sufficient sample counts.
  • Keep query strings, raw URLs, page contents, and unrestricted user identifiers out of the event contract.
How to test this use case

Measure Frontend performance monitoring with SQL and check the results

To measure frontend performance monitoring with sql, choose one workflow and its owner. Define the events, test them with known inputs, and write a query that answers a specific question.

  1. 1

    Choose when to log

    Choose the product routes and supported performance metrics that matter.

  2. 2

    Capture the outcome

    Begin with frontend_vital_measured, frontend_navigation_completed, frontend_resource_failed and document the grain of each event.

  3. 3

    Check the stored rows

    Review samples and thresholds for each route before alerting on a release.

  4. 4

    Make the decision

    Which routes have the lowest share of passing samples?

Agent prompt

Paste this into your coding agent

Replace YOUR_API_KEY after signup, then ask the agent to run the product flow and verify the first events.

agent prompt

Frontend performance monitoring with SQL setup prompt

text
Instrument frontend performance with Telemetry.

Use /skill.md and this Telemetry API key: YOUR_API_KEY

Add typed frontend_vital_measured events with route_template, release, metric_name, metric_value, metric_unit, threshold_version, passed, device_class, and environment.

Create SQL and a dashboard for sample count, LCP, INP, CLS, and passing-sample rate by route and release. Require a reviewed minimum sample count before comparing releases or enabling an alert.

Use route templates, bounded device classes, and versioned thresholds. Do not log raw URLs, query strings, DOM content, form values, cookies, auth tokens, or unrestricted user identifiers.

Setup steps

  1. 1Choose the product routes and supported performance metrics that matter.
  2. 2Emit typed browser measurements with route, release, threshold version, and environment.
  3. 3Send synthetic passing and failing samples from a test release.
  4. 4Review samples and thresholds for each route before alerting on a release.

Events to capture

frontend_vital_measuredfrontend_navigation_completedfrontend_resource_failedfrontend_release_observed

Questions you can answer

  • Which routes have the lowest share of passing samples?
  • Did the latest frontend release change LCP, INP, or CLS?
  • Does performance drop across devices or only in one device class?

Example event schemas

Check what each event records, when to send it, and which field types it needs. Review the example payload and privacy checklist before using it in production.

Use these queries in Telemetry

Learn about Alerts

Add a threshold and recipients to your reliability query to get alerts.

Related SQL recipes

More SQL recipes

Run the query using this workflow's event fields and check the example result. Save the result to a dashboard or set up an alert.

Browse all recipes
Recipe collectionsFrontend reliability SQL

Next step

Create the API key your agent will use

The free plan is enough to run the prompt, send test events, and review the first dashboard.

Related pages