Monitoring
Overview
Monitoring reports what your API does in production: which requests fail, which are slow, what changed in the release that broke them, and which commit is the likely cause.
Turning monitoring on bakes the connection into your generated SDKs. There's no separate agent to deploy and no instrumentation code to write. Rebuild the SDK after enabling it and your clients start reporting.
The tabs
Every event, newest first. Where you land when something just broke.
Errors grouped into problems, with triage, comments, and suspect commits.
Follow one request across services and see where the time went.
Latency percentiles per endpoint, so a slow tail is visible.
Health per deploy, and what likely caused a regression.
Scheduled checks that call your endpoints and tell you they're down.
Fire on a burn rate or a saved search, not on every error.
The query bar and filter builder every tab shares.
Getting started
- Enable it
One toggle on the project's Monitoring tab. See Setup.
- Rebuild your SDKs
The telemetry config is compiled in at build time, so already-published versions report nothing.
- Upload symbols
Otherwise production stack traces are unreadable. See Readable stack traces.
Live by default
Events stream to the dashboard as they arrive, so an incident updates in front of you without a refresh.
What's kept
Raw events are kept for 30 days. Charts survive past that on hourly rollups, so a 90-day trend still renders even though you can't open an individual event from three months ago.
Your plan includes a monitoring storage allowance; usage against it is shown in the dashboard.
Further reading
Background rather than instructions, on the blog.