1What FoxPlug reads from Sentry
These are the exact things it reads, and nothing else.
| What | The details it takes |
|---|---|
| Releases of your organisation | version, shortVersion, dateReleased (else dateCreated); the 50 newest releases are requested, and only those newer than the last read (7 days back on a first read) become moments |
| Hourly error counts for the whole organisation, last 14 days | sum(quantity) of category error at a 1 hour interval over 14 days (336 points), added up across every project into one series; stored on the connection as the series start, step, the counts, the 14 day total and the time fetched |
| Your organisations, for the picker | slug and name of each organisation the token can see, so you pick a name instead of typing the slug |
| The errors one cancelling customer hit | for a Stripe cancellation in the last 30 days: events matching that customer's email (the email Stripe holds), fields title, transaction and timestamp, up to 50 events over 30 days; only those in the 2 days before the cancellation are used |
| Stored error counts reused by the launch snapshot and the monthly update | no extra Sentry call for the monthly update (it reads the stored series: errors in the last 7 days against the 7 days before); the launch snapshot first asks the hourly pull for a fresh series, then compares errors since the launch with the hours before |
2Moments it finds, and what each becomes
A moment is one thing that happened in Sentry worth a second look. Each one is scored, then it becomes a post, a changelog entry, a thing to fix or an idea to email, or it is skipped.
a new release appears in your Sentry organisation
The moment is titled like this: Shipped release 2.4.1
You cut release 2.4.1 of a made-up app called Trailmap. When you press Check for what's new, FoxPlug writes the moment 'Shipped release 2.4.1' with the line 'Cut a new release (2.4.1) - tracked in Sentry for trailmap-hq.' It then goes through the normal scoring like any other update, so it can become a post or a changelog entry.
errors jump in the 48 hours after one of your deploys
The moment is titled like this: not a milestone: a fix-first card in the Today brief, 'Errors are 4.7x higher since you deployed. Fix before you post.'
You deployed on Nov 3 at 09:00 UTC. The 48 hours after hold 94 errors against 20 in the 48 hours before. That is at least 30 and at least 3 times the before count, so the Today brief shows the fix line with the why: 94 errors after, 20 before, with a link to your Sentry issues page.
a launch is running and errors since launch are well above the usual hour
The moment is titled like this: not a milestone: the launch snapshot's fix line, 'Errors have jumped since the launch started.'
Launch mode is on. Since it started there are 60 errors, 10 an hour, against about 2 an hour before. That is at least 20 errors and 3 times the usual hour, so the launch snapshot names it as the fix line.
a Stripe customer cancels and has errors in Sentry under their email
The moment is titled like this: not a milestone: one plain line in the Why they left note
The line reads like: 'Acme cancelled Tue. Their last visit: 2 pages, 1 day before (PostHog). They hit errors on /export (3 times) in the 2 days before (Sentry).' It is facts only, never a guessed reason.
you press Draft my monthly update
The moment is titled like this: not a milestone: a Reliability line in the monthly update draft
The draft gets a line such as '412 errors in the last 7 days, down from 530 the week before', with the source noted as Sentry and the day it was pulled. Needs at least 300 hourly points stored.
3How the brain uses it
The rules below are the ones that apply to Sentry. The same rules, with worked examples, are on the brain page.
- Errors in the 48 hours after a deploy are at least 30 and at least 3 times the 48 hours before (before counted as at least 10): the first card in the Today brief, 'Errors are Nx higher since you deployed'. Deploys from 12 hours to 5 days ago are checked; the worst ratio wins. How the brain decides
- Why they left is one plain line built from facts only (last visit, errors in the 2 days before), never a guessed reason. How the brain decides
- Reads happen when you press Build the brief or Check for what's new, nothing in the background. How the brain decides
- Reads are read-only: nothing is changed in your other tools. How the brain decides
4Set up Sentry in a few steps
Access: personal auth token plus your organisation slug (a second box). What to give it: auth token, org:read + project:read + project:releases + event:read.
- Open Sentry's auth tokens page (Account dropdown, or User settings, then Personal Tokens).
- Click Create New Token and name it FoxPlug.
- Tick exactly four permissions: org:read, project:read, project:releases and event:read.
- Click Create Token, copy it and paste it into the first box in FoxPlug.
- In the second box give your organisation's short name: the YOUR-SLUG part of sentry.io/organizations/YOUR-SLUG/ (also under Settings, General Settings, Organization Slug). A picker can list your organisations once the token is in.
- Press Connect.
5Limits worth knowing
Where it stops, so nothing surprises you.
- Releases: the 50 newest are requested and anything older than the last read (7 days on a first read) is skipped.
- Error counts cover the last 14 days at 1 hour steps for the whole organisation; the brief cannot split them per project.
- A refused token (401 or 403) parks the connection in error with a reason and asks you to reconnect with a read-only token; a failed read keeps the last stored numbers.
- The deploy comparison needs a deploy milestone from Vercel, Netlify or Sentry releases between 12 hours and 5 days old, and looks at the 6 newest.
- The cancelling-customer lookup works only when your Sentry events carry the user's email; otherwise the line says it could not match them.
- The monthly update line needs at least 300 stored hourly points.
6What it never reads
Read only means read only, and the list below is what the code leaves alone.
- Event contents or issue titles in the hourly error count (only counts are stored)
- Your source code (no address that returns it is called)
- Anything it writes back: no issue is resolved, assigned or edited
- Your token after it is saved: it stays in the vault and is never returned to the browser
7Questions
Can FoxPlug see my Sentry stack traces or issue details?
The hourly count pull stores only numbers: how many errors per hour. The one place event fields are read is a customer cancellation lookup, which asks for title, transaction and timestamp of events under that customer's email in the 2 days before they cancelled. Nothing else is stored or shown.
Why does FoxPlug need an organisation slug as well as the token?
Sentry's release and statistics calls are made per organisation, so the slug goes into every request. It is the YOUR-SLUG part of sentry.io/organizations/YOUR-SLUG/, and a picker can list yours once the token is saved.
Does it watch Sentry all day and message me?
No. FoxPlug reads Sentry only when you press Check for what's new or Build the brief. A spike shows up as the first card in the Today brief next time you press it.
Which permissions does the token need?
Four: org:read, project:read, project:releases and event:read. The in-app guide says event:read is there so FoxPlug can look up the errors a cancelling customer hit, and that FoxPlug reads nothing else and never writes.
What happens when the token expires?
Sentry answers 401 or 403, FoxPlug marks the connection as in error with the reason, and asks you to reconnect with a read-only token. The last stored numbers stay until then.
FoxPlug reads this tool only when you press Check for what's new, and only to read. Plans and limits are on the pricing page. Questions: support.