Practise the standard verbs for tracking releases and errors together in Sentry.
0 / 5 completed
1 / 5
Fill in: 'We ___ every deploy with a Sentry release so a new error can be tied to the exact commit that introduced it, rather than just to a vague point in time.'
We 'tag a deploy' — the standard, established Sentry collocation for associating errors with a specific release version. The other options aren't the recognised term here.
2 / 5
Fill in: 'Deploying without creating a matching Sentry release can ___ a spike in errors showing up with no clear link back to the change that actually caused it.'
We say a missing release will 'leave' errors unlinked to their cause — the standard, natural collocation for the resulting confusion. The other options aren't idiomatic here.
3 / 5
Fill in: 'We ___ the error rate for a new release closely in the first hour after deploy, since a sharp jump there is often the earliest signal of a regression worth rolling back.'
We 'monitor' an error rate — the standard collocation for ongoing observation of a post-deploy health metric. The other options aren't idiomatic here.
4 / 5
Fill in: 'We ___ source maps to every JavaScript release upload, so a minified stack trace resolves back to readable source lines instead of an unreadable bundle offset.'
We 'attach source maps' — the standard, established collocation for linking build artefacts needed to decode stack traces. The other options aren't the recognised term here.
5 / 5
Fill in: 'We ___ a new error against the release history first, since one that only appears from a specific version onward almost always points straight to what actually broke.'
We 'check' an error — the standard, simple collocation for cross-referencing it against release data during triage. The other options are less idiomatic here.