Know which deploy broke it.
Tag every event with a release and an environment. A new issue that starts at 2.14.0 is obvious, and staging noise never gets mistaken for a production fire.
// tag every entry as you send it
body: JSON.stringify({
logs: [{
message: 'checkout failed',
level: 'error',
release: 'checkout@2.14.0', // git sha or version
environment: 'production', // vs staging, preview
}],
})
// then filter the stream by either one
GET /api/projects/{id}/logs?environment=productionHow it works
01
Stamp every event
The release and environment are attached to each error automatically once you set them at init.
02
First-seen points at a deploy
Each issue records the release it first appeared in, so a regression names its own cause.
03
Environments stay separate
Production, staging, and preview report side by side without drowning each other out.
Per release
Every issue knows the version it was born in.
Per environment
Production fires never hide behind staging noise.
Regression aware
A resurfaced issue after a deploy is easy to catch.