Find the errors affecting your users.

Errors are grouped by cause, so a spike is one issue with a count rather than a wall of near-identical rows. Each issue opens with its stack trace, the release it first appeared in, the users it reached and the request that produced it.

GroupingBy cause, not message
Your SDKSentry-compatible
AttachedTrace, logs, replay
Issues · checkout-api13 unresolved
is:unresolvedservice:checkout-apisort:freqLast 24h
Events / min105+318%
Users affected440
New today3
Since releasev2.14.013:58
RangeError: retry budget spentpayments-worker · retry.ts33
New
TimeoutError: pool exhausted after 2000mscheckout-api · db.acquire1 333412
Regressed
TypeError: cannot read "total" of undefinedweb · CartSummary.tsx:4121296
New
ValidationError: card expiry in the pastcheckout-api · cards4139
AbortError: signal is aborted without reasonweb · useCart.ts:881811
ECONNRESET upstreampayments-worker94
Resolved
IssueMON-4821

TimeoutError: pool exhausted after 2000ms

Regressed
v2.14.0
prod
first seen13:58 · v2.14.0
last seen2s ago
events1 333
assigneePriya R.
Stacknode 20
  1. Pool.acquiredb/pool.ts:118
  2. createOrderorders/create.ts:44
  3. checkoutHandlerhttp/checkout.ts:31
  4. processTicksAndRejectionsnode:internal/process/task_queues:95
Linked
INC-402 · Checkout latency above target
Trace a41f…9c2 · 2.41s

From a new error to its cause

A new issue carries the release that shipped it and the request that raised it. Here is one error, from the first event to the explanation.

INC-402 · Checkout latency above SLO
Resolved
14:02:11 → 14:19:44 · 17m 33s
14:02:04
New issue, seven seconds after deploy 2f91c
Fingerprinted as a new issue rather than folded into an existing one, and tied to the release.
Errors
14:02:11
Rate threshold crossed, alert raised
The route fires on the error rate rather than on the first event.
Alert routes
14:11:26
Cause found in the attached trace
The connection pool ceiling is visible in the trace attached to the issue.
Traces

Group, investigate and triage issues

How errors are grouped, what arrives attached to each issue, and how a team keeps the list under control.

Fingerprinting by cause

Group on frames, exception type and a normalised message, so an id in the text does not split one issue into a thousand.

fingerprint
Readable stack traces

Source maps and debug files applied on ingest, with your own frames separated from library frames.

sourcemaps
Release and regression tracking

First seen in, last seen in, and a re-opened flag when something you resolved comes back.

releases
Who it reached

Distinct users affected alongside the event count, so you can judge how widely an error has spread.

impact
Attached context

Breadcrumbs, the request, the trace, the surrounding logs and the session replay, on the issue itself.

context
Triage that sticks

Assign an issue, resolve it in the next release, mute it with an expiry, or mark it as noise.

triage
Your existing SDK

Point an existing Sentry SDK at Moneat by changing its DSN, keeping your instrumentation as it is.

dsn

Open an issue with its context attached.

Each issue arrives joined to the request that produced it and to the telemetry around that request, so the next step is a click rather than a second search.

  • The failing request. Method, route, parameters, headers and the user it belonged to.
  • The trace it lived in. One click to the span that was slow in the request that raised this.
  • The logs around it. The lines from the same request, already filtered to it.
  • The session replay. For browser errors, the recording of what the person was doing.
TimeoutError: pool exhausted1 284 events · 311 users
First seen
14:02:04 · release 2f91c
Last seen
14:19:31
Users affected
311
Route
POST /api/checkout
Frame
db/pool.ts:88 acquire()
Trace
a41f…9c2 · 12 spans
Assigned
Priya Raman

Start catching your errors.

Point your SDK at Moneat, upload your source maps, and see grouped issues on your next deploy. Start on the free plan with no card.