A Sentry dashboard that counts issues instead of streaming them
Unresolved issues, regressions, and unhandled errors for one project — with two read scopes and nothing more.
Get early access to the Sentry integration
dev-views is in active development. Join the waitlist and we will note your interest in Sentry.
Sentry is very good at telling you about an error the moment it happens and much less good at telling you how you are doing overall. The issue stream is ordered by recency, which means a regression of something you fixed last month looks exactly like a new problem, and an issue quietly escalating from twelve events a day to twelve hundred looks like nothing at all until it reaches the top.
dev-views reads one Sentry project and turns that stream into counts. Regressions are their own reading. So are escalating issues, unhandled errors — the ones nothing caught, which reach the user as a crash — and the fourteen-day event volume behind all of it. Two read scopes are enough, and a token with only those cannot resolve an issue or change a setting.
What dev-views reads from Sentry
21 readings, computed from the Sentry API. There are no defaults — you choose which become tiles and in what order, because guessing which of 21 matters to you would be wrong for most people.
Unresolved issues
Issues currently open in the project, with new arrivals over 24 hours and 7 days tracked separately so a spike is distinguishable from a backlog.
Regressions
Issues you had marked resolved that have come back. In a recency-ordered stream these are indistinguishable from new errors, which is exactly why they deserve their own number.
Escalating
Issues Sentry has flagged as getting significantly worse — the ones changing in severity rather than simply existing.
Unhandled
Issues from errors nothing caught. These reach the user as a crash, which makes them a different category from an error you logged deliberately.
Noisiest issue
The open issue producing the most events, with its event count beside it — usually the one worth fixing first on volume alone.
The full list
- Unresolved issues
- New issues, 24h
- New issues, 7 days
- Active issues, 24h
- Regressions
- Escalating
- Unhandled
- Resolved, 14 days
- Fatal issues
- Error issues
- Warning issues
- Events, 14 days
- Users affected
- Events per issue
- Noisiest issue
- Noisiest issue events
- Latest release
- Platform
- Project status
- First event
- Created
How the connection works
- 01Create an auth token in Sentry under Settings → Auth Tokens.
- 02Grant exactly two scopes: project:read and event:read. Do not substitute org:read — a token with only that authenticates successfully and then sees nothing.
- 03Paste the token into dev-views. Connecting verifies it by listing projects, which is what catches the org:read mistake immediately rather than leaving you with an empty dashboard.
- 04Pick the project to watch and choose which of the 21 readings become tiles.
- Credential
- A auth token (sntrys_… or a 64-character token), created under Settings → Auth Tokens.
- Watches
- One project, chosen after connecting.
- Refresh
- Every 60 seconds, cached per user so browsing does not re-spend your API budget. A manual refresh forces a read immediately.
- Storage
- Encrypted with AES-256-GCM before it is stored. The encryption key lives in the environment, never in the database, and the credential is never sent back to the browser.
Read-only is enough
Grant these and nothing else. A credential scoped this way cannot change anything, whatever software is holding it.
- project:readthe watched project and its releases
- event:readissues, event counts, and affected users
What your dashboard shows
- Issue counts rather than an issue stream: how many are open, how many are new, how many came back, and how many are getting worse.
- Severity split into fatal, error, and warning, so a hundred warnings do not read the same as a hundred fatals.
- Event volume over fourteen days alongside users affected, counted per issue — someone who hits three separate issues is counted three times, which is stated rather than hidden.
- A fatal issue or a regression raised in the attention band above the dashboard whether or not you chose that tile.
Who this is for
- Solo developers running one production application who want error health as a number rather than a feed to scroll.
- Anyone who has fixed a bug, marked it resolved, and not noticed when it came back three weeks later.
- Developers who want unhandled crashes separated from deliberately logged errors, because only one of those is reaching a user.
Sentry questions
Which Sentry metrics does dev-views track?
Twenty-one readings for one project: issue counts covering unresolved, new in the last 24 hours and 7 days, active again in the last day, regressions, escalating, unhandled, and resolved in the last fortnight; severity counts for fatal, error, and warning; volume covering total events over 14 days, users affected, mean events per issue, and the noisiest issue with its event count; and project facts including latest release, platform, status, first event, and creation date.
What scopes does the Sentry token need?
Two, both read: project:read for the watched project and its releases, and event:read for issues, event counts, and affected users. A token with only those cannot resolve an issue, change a setting, or touch anything else in your organisation. Deliberately not org:read — it is the scope people grant instead of project:read, and a token holding only it authenticates fine and then sees nothing, which is why connecting verifies by listing projects.
What counts as a regression?
An issue you had previously marked resolved that has fired again. Sentry tracks this state itself; dev-views surfaces it as a standalone count because in a stream ordered by recency a regression is visually identical to a brand-new error, and the two mean very different things about the state of your code.
How is 'users affected' counted?
Per issue, then summed. Someone who hits three different open issues is counted three times. That makes it a measure of impact spread across issues rather than a distinct-user count, and dev-views says so in the metric's own description rather than letting it be misread as unique users.
What window do the issue counts describe?
Fourteen days for event volume and resolved counts, which is the period Sentry's stats endpoint is queried for. Shorter readings — new issues in 24 hours, active issues in the last day — use their own windows, and each metric states which one it means.
Works alongside
dev-views is most useful when more than one service is on the board. These are the ones people connect next to Sentry.
Watch Sentry alongside the rest of your stack
One read-only surface for every service you run. Join the waitlist for early access.