How it works
GitHub notifications bury real releases under comments, pull requests and commits. Release Radar looks only at releases, and puts security fixes and breaking changes at the top of a digest you can read in five minutes.
The pipeline, in plain words
- 01
Load. Every Monday at about 8 AM IST the scheduler wakes the app, which reads the repo list you maintain on the Repos page. Opening the dashboard does the same pull on demand, so you are never waiting a week to see what shipped.
- 02
Fetch. For each repo it asks GitHub for releases published in the past 7 days. Drafts are dropped and pre-releases are labelled. A repo that can't be reached is listed under “Couldn't check” with the reason, never skipped silently.
- 03
Check with rules. Fixed pattern matching runs on every release: CVE and GHSA ids, security words, “breaking change” phrases, and a major version bump compared with the repo's earlier releases. Each hit keeps the exact text that triggered it.
- 04
Read with AI. Gemini Flash reads the release notes, in batches of up to 8, and writes a short summary, a category (security, breaking or routine), the reason, and what to check. Results are stored by GitHub release id, so a release is analysed once, ever.
- 05
Merge. A release is flagged if the rules flagged it or the AI did. Flags are never removed, and every release in the window stays in the digest.
- 06
Deliver. The digest is saved, shown on the dashboard, and emailed, even in a quiet week, so no email means something broke.
Which repos does it watch?
A fixed list, not a search. The app watches exactly the repos on the Repos page and nothing else. It does not discover repos, and it does not filter by industry, topic, stars or language. The starting list of 22 was picked by hand, leaning on payments (Stripe, Razorpay, Adyen), authentication (next-auth, jose, Keycloak, Auth0) and web basics (Express, axios, Fastify), and each one was checked against live GitHub first.
Two kinds of repo. A dependency is a library or service we ship against, where a security fix or breaking change matters most. An evaluating repo is a tool we are considering, and it also gets a cadence and momentum line (how often it releases, how fast its stars are growing).
Anyone can add to it. If a colleague recommends something, or whoever looks after the dashboard wants to keep an eye on another project, they paste owner/name or a GitHub link on the Repos page. No code changes and no redeploy.
What happens when you add one. The app checks that the repo exists on GitHub and is public, that it is not already tracked, and that the list is under its 40-repo limit. If the repo is archived or has never published a GitHub release, you get a warning but it is still added. From then on it is pulled automatically: the next time the dashboard opens (within minutes) its last 7 days of releases appear, and it is part of Monday's digest. Older releases show up in the 30 and 90-day views after you press Backfill.
Only public repos can be watched, and only what they publish as GitHub releases. If a new repo releases a lot at once, rule flags appear immediately and AI summaries fill in over the next refreshes, because AI calls are capped to protect the free quota.
Who does what
| Part | Responsible for | Power |
|---|---|---|
| AI (Gemini Flash) | Summary, category (security / breaking / routine), the reason, the suggested check. | Can add a flag. Cannot remove one. |
| Rules (plain code) | CVE and GHSA ids, security and breaking keywords, major version bumps, ordering and cadence numbers. | Always runs, always wins a disagreement. |
| Human (you) | Deciding what matters to your product, and what your team does about it. | The AI says what a release contains. It never judges whether it affects you. |
The AI decides what to raise, never what to bury.
That is why a rule flag survives an AI that says “routine”: the dashboard shows both opinions (“Rule flagged; AI judged routine — check the notes”) and leaves the decision to you.
Known limits
- Only GitHub releases are covered. Vendors that announce API changes on their own changelog site, and projects that push tags but never publish a release (braintree_node, node-jsonwebtoken and passport are three examples we found), are invisible here.
- Silent security fixes can't be found. If a maintainer fixes a vulnerability without saying so in the notes, nothing that reads the notes can detect it.
- Not real-time alerting. Data is pulled when someone opens the dashboard and on the Monday run. A security fix published while nobody is looking is first seen at the next visit or in Monday's email. GitHub webhooks would fix that, but they need admin rights on the repos you watch.
- A missed flag lowers a release, it doesn't hide it. If the AI fails to flag something and no rule matches, the release still appears, just lower down. Risk is reduced, not removed.
- Very long notes are partly read. The AI sees the first 6,000 characters plus any lines further down that mention security or breaking changes. Anything else deep in a huge changelog isn't shown to it.
- The rules are deliberately noisy. A single word like “security” raises a flag. That means some false alarms, which is the intended trade: a false alarm is cheap, a missed security fix is not.
- Free-tier limits. Gemini's free quota is small, Vercel's cron fires anywhere inside the scheduled hour, and Resend's free plan only delivers to the account owner's own address.
- No login. This is a course project. Anyone with the link can edit the repo list or press “Run now”. Manual runs have a cooldown and a daily AI-call cap to protect the quota.