Infrastructure · We run it ourselves
Sentry captures unhandled errors and slow transactions from running software, groups them into issues, and ties each one to the release and the commit that introduced it.
The number that matters in observability is not how many errors a system produces — it is how long the system runs broken before a human learns about it. Without instrumentation, that interval is set by the user who is annoyed enough to write in, which in a business tool is measured in days and in a consumer flow is measured in never. Sentry in mozg replaces that with an event that arrives before the report does, and the honest cost of it is that the arrival is now a stream someone has to own.
01
The detection interval, not the error count, is the operational figure. A checkout that has been failing for one user since Tuesday and a checkout that has been failing for every user for eleven minutes produce very different bills, and a support inbox cannot tell them apart. An SDK that reports on the exception path collapses the interval between the break and the first informed human to roughly the network round trip, which changes what an on-call rotation is actually for.
02
An error budget is only real when the denominator is measured. Saying a service should be up 99.9 per cent of the month means nothing until something counts sessions and marks each one crashed or clean; release health does that, and the budget becomes a number that can be spent — so many bad sessions this month, and when they are gone the next deploy waits. Without the counter, availability targets are a slide, and every incident is argued from memory.
03
Grouping is the property that makes the stream survivable. One bad deploy can emit tens of thousands of events; what an engineer can act on is one issue with a count and a first-seen timestamp. The corollary is that grouping quality is the whole product — when a fingerprint splits one fault across forty issues, or fuses forty faults into one, the tool has stopped being observability and become noise with a dashboard.
04
Attribution to a release closes the loop that logs cannot. An issue that appears with the version stamp of the deploy from twenty minutes ago is a diagnosis, not a clue, and the rollback decision is made on that one line rather than on a bisect. This is why the SDK is worth wiring into the build rather than only into the runtime: without source maps and a release marker uploaded at build time, a minified stack trace from a Next.js bundle is unreadable and the whole chain breaks at the last step.
05
@sentry/nextjs is one package covering three runtimes that fail differently — the browser, the Node server and the edge — and in a framework where a render can throw on the server and hydrate wrong on the client, an error caught in only one of them is a partial picture. mozg is a turborepo monorepo, so the same instrumentation has to hold across packages that ship independently and still resolve to one release identity.
06
Performance data belongs on the same spine as errors because slow and broken are the same incident seen at different thresholds. A database call that has crept from 40 ms to 4 s does not raise an exception; it raises a timeout somewhere three services away, and the exception lands on the innocent party. Traces put the two on one timeline, which is the difference between fixing the symptom and fixing the query.
07
The instrumentation has to be part of the repository, not a console setting, or it decays. In mozg it sits alongside the versioned Prisma migrations and the compose files, which means the observability configuration is reviewed, diffed and rolled back with everything else — and a colleague who joins can read why an issue is muted instead of discovering it in a web UI three incidents later.
An entry that cannot point at something you can open, run or read does not compile. That is a property of the type, not a promise in a paragraph.
Invariant
Sentry tells us that something threw, not that something is wrong. The failures that cost the most money are silent and successful: a webhook that returns 200 while writing nothing, a sales agent that answers every message fluently and with the wrong price list, a nightly job whose schedule quietly stops firing. None of these raise an exception, so none of them reach an error tracker, and a team that has been trained to treat a quiet Sentry as a healthy system will find these late and by invoice. There is also a hard economic edge — event volume is billed, and the incidents worth the most attention are exactly the ones that emit the most events, so the first big outage is also the month the quota is exhausted and sampling starts discarding the evidence. Under that pressure teams tune sample rates and mute noisy issues until the tool reports what is comfortable rather than what is true. Error tracking is the floor of observability, not the whole of it; correctness needs assertions on business outcomes and heartbeat checks on things that are supposed to happen, and those have to be built.