Monitoring
Runtime errors
inline collects the crashes your users hit, groups them into one issue per distinct bug, and traces each one back to the code that shipped it. Link a project to a repository and the root-cause analysis names the change.
Creating projects and setting the workspace defaults are admin tasks. Everyone with observability access can read the issues and work through them.
#Setting up a project
A project is one application. Create one under Projects, point your application at it, and its crashes start arriving.
Link that project to a repository and inline can do the part that matters: read the code the crash came from and say which change introduced it.
#Reading the issues
Runtime errors
Every crash your users hit, grouped, symbolicated, and root-caused against the code that shipped it.
Unresolved
23
Fix now (P1)
2
Regressed
1
With a suggested fix
6
Event volume
Occurrences per hour across every project in this workspace
Needs attention
Issues is one row per distinct bug, so a crash that happened four thousand times is one row with a count on it. Each carries how many events and how many people it affected, and when it was last seen.
The priority badge comes from triage rather than from volume, which is why a rare crash in checkout can outrank a common one in a settings screen.
| Priority | What it means |
|---|---|
| P1 · fix now | Serious and worth interrupting someone for. |
| P2 · this week | Real, and it can wait for the current cycle. |
| P3 · backlog | Worth recording, not worth scheduling. |
| P4 · noise | Expected, or outside your control. |
Unresolved, Fix now (P1), Regressed and With a suggested fix sit across the top. Regressed is the one to watch: it means an issue you had closed has started happening again.
#What caused it
Open an issue and inline gives you the crash grouped and symbolicated, with its analysis of what went wrong in the code that shipped it. Where it can propose a fix, the issue is marked and counted under With a suggested fix.
Event volume above the list plots occurrences per hour across every project, over 24h, 7d or 30d, which is how you tell a new bug from a bug that has always been there.
#Workspace defaults
The Observability Settings tab sets what happens to everything arriving. Triage new issues and Root-cause analysis turn the two analysis passes on and off, Minimum level decides how much is kept at all, and Event retention how long it stays.
Minimum level runs from debug — everything up to fatal only, with info and above (default) in the middle. Raising it is the lever to reach for when a chatty application is filling the list with things nobody will act on.
Email on new P1 issues is the one notification that fires from here. A project can override the per-project values, so a noisy internal tool need not change the workspace default.
Runtime errors are included with Pro. See Plans and billing.