What the integration does
Sentry is Vesqo's measure of how the product is holding up. Every fifteen minutes it reads the project's error count for the hours since the last sync, and every issue seen for the first time. When your SDK stamps events with a release, Sentry knows every version that ran, and those become releases in Vesqo too, so a spike can be dated to what shipped even without GitHub connected.
On its own an error count is a chart. Vesqo sets the hours after a release against the same hours of the week before, and when the rate at least doubles on a meaningful count, it writes a signal. New issues seen in the same window make it a stronger one. The hour under way counts for the minutes observed so far, so a bad release shows minutes after it went out, not at the top of the next hour.
What Vesqo reads from Sentry
- The hourly count of error events for one project.
- Issues: each new issue's title, the first time it was seen, and the users it hit, when events carry a user.
- Releases, when the SDK sets one.
- Nothing is written to Sentry. Vesqo does not read event payloads, breadcrumbs or source maps, and cannot resolve or assign an issue.
How it connects
Install the Vesqo integration from Sentry's side with one click (the organization comes with the install, the project is chosen after, tokens refresh as they expire), or paste a user auth token with org:read, project:read and event:read. To have signals name the customers an error hit, tag events with the user in your SDK: Sentry.set_user(email: current_user.email). To have deploys come in as releases, set release in the SDK's config.
Why connect Sentry
Sentry tells you an issue has 340 events and 12 users. It cannot tell you that two of those users are the admins of your two largest customers, that both tried to pay after the error and could not, or that six support conversations opened in the same half hour about the same screen. Vesqo can, because it reads the same hours in Stripe, PostHog and the inbox.
That changes which bug gets fixed first. Sentry ranks by volume; Vesqo ranks by the paying customers in it and the money at stake, and says so in the morning brief.
Questions Vesqo can answer with it
- Which paying customers hit the errors after v2.14.0?
- How much MRR is behind the users on this Sentry issue?
- Did errors rise after the last release, compared with the same hours last week?
- Which issues from this week hit customers who pay more than €200 a month?
- Did support hear about this before we did?
Signals it writes
- Release regression: the error rate after a release at least doubled against the week before, on a meaningful count; new issues in the window make it stronger.
- Release impact: for a release that hurt, one card with the errors, the key event, the inbox and the money together: what support heard, the payments that failed in the window, and the MRR of the customers behind them.
- Customers hit: when events carry a user, each signal names the accounts behind the errors, with what they pay.