A GitHub metrics dashboard for one repository
Open pull requests, commit velocity, and CI results for one repository, without opening GitHub.
Get early access to the GitHub integration
dev-views is in active development. Join the waitlist and we will note your interest in GitHub.
GitHub answers a lot of questions well, but it answers them one page at a time. Open pull requests are on one tab, the Actions history on another, the release list on a third. Checking whether a repository is in good shape means visiting all of them, and doing it again tomorrow.
dev-views reads a single repository through the GitHub API and puts the readings you choose onto one surface. It never writes: it cannot open a pull request, push a commit, or re-run a workflow. It reads with your own personal access token, so it only ever sees what you can already see.
What dev-views reads from GitHub
30 readings, computed from the GitHub API. There are no defaults — you choose which become tiles and in what order, because guessing which of 30 matters to you would be wrong for most people.
Open pull requests
Pull requests currently open, with drafts and review-requested counted separately so a queue of three drafts does not read as three things waiting on you.
CI success rate
The share of the last 30 Actions runs that passed. A rate that drifts down is visible long before any single run looks alarming.
Commits, 7 days
Commits to the default branch in the last week, alongside a 30-day figure and the distinct authors behind them.
Oldest open PR
The age of the longest-open pull request — the number that catches work quietly rotting at the bottom of the list.
Last workflow run
The result of the most recent Actions run, plus how many runs failed in the last 24 hours.
The full list
- Open pull requests
- Draft pull requests
- Awaiting review
- Oldest open PR
- Open issues
- Oldest open issue
- Commits, 7 days
- Commits, 30 days
- Last commit
- Contributors, 30 days
- Merged PRs, 30 days
- Last workflow run
- CI success rate
- Failed runs, 24h
- Latest release
- Releases
- Stars
- Forks
- Watchers
- Views, 14 days
- Unique visitors, 14 days
- Clones, 14 days
- Last push
- Branches
- Default branch
- Primary language
- License
- Repository size
- Created
- Visibility
How the connection works
- 01Create a personal access token on GitHub with the repo and read:user scopes. Fine-grained tokens work too.
- 02Paste it into dev-views. The token is verified against the GitHub API before anything is stored.
- 03Pick the repository you want to watch from the list the token can see.
- 04Choose which of the 30 readings appear as tiles, and drag them into the order you want.
- Credential
- A personal access token (ghp_… or github_pat_…), created under Settings → Developer settings → Personal access tokens.
- Watches
- One repository, 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.
- reporead the repository, its pull requests, issues, and Actions runs
- read:userconfirm which account the token belongs to
What your dashboard shows
- A row of tiles showing only the readings you picked — there are no defaults, because guessing which of thirty matters to you would be wrong for most people.
- An attention band above the dashboard that surfaces a failing workflow or a rejected token whether or not you added that tile, so the metric you never thought to watch is still the one that reaches you.
- A 14-day trend behind readings that have one, and the repository's own deep link on every tile for when you do need to open GitHub.
Who this is for
- Solo developers maintaining one production repository who want the pull request queue and CI state visible without a tab.
- Maintainers of a public project tracking stars, forks, and release cadence next to the actual work in flight.
- Anyone who has merged a pull request into a red default branch because the Actions tab was one click too far away.
GitHub questions
Which GitHub metrics does dev-views track?
Thirty readings for one repository, grouped as work in flight (open, draft, and review-requested pull requests, open issues, and the age of the oldest of each), velocity (commits over 7 and 30 days, distinct contributors, merged pull requests, time since the last commit), continuous integration (last workflow result, success rate across the last 30 runs, failures in the last 24 hours), releases, audience figures including stars and traffic, and repository facts such as default branch, primary language, licence, and size.
Does dev-views need write access to my repository?
No. dev-views only ever reads. The repo scope is what GitHub requires to read a private repository's pull requests and Actions runs — GitHub does not offer a narrower read-only equivalent for private repositories. For a public repository you can use a fine-grained token with read-only permissions instead. dev-views has no code path that writes to the GitHub API.
Why are the traffic metrics empty?
Views, unique visitors, and clones come from GitHub's traffic endpoint, which requires push access to the repository. If your token cannot reach it, dev-views still renders the tile and explains why it is blank rather than silently showing a zero. Every other reading works with read access.
How often do the numbers update?
Every 60 seconds. Responses are cached for that window per user and repository, so browsing between pages does not re-spend your API budget — a dashboard render costs about a dozen GitHub requests against a 5,000-per-hour limit. There is also a manual refresh button when you want the current state immediately.
Can I watch more than one repository?
One repository per connected token today. The stored scope is a single owner/name pair, and the pull request, issue, and Actions readings are all computed against it.
Works alongside
dev-views is most useful when more than one service is on the board. These are the ones people connect next to GitHub.
Watch GitHub alongside the rest of your stack
One read-only surface for every service you run. Join the waitlist for early access.