GitHub Repo Monitor — Release Tracker, Star Velocity & Activity Alerts

GitHub Repo Monitor is a fast, reliable GitHub release tracker and OSS monitoring tool that watches any list of public GitHub repositories — new releases, star velocity, issues, commits and contributors — using the open GitHub REST API. No scraping, no browser, no proxies, nothing to get blocked. Point it at your dependency list, your competitors' repos, or a VC watchlist, and get clean, structured JSON in seconds. Turn on monitor mode and each scheduled run returns only what changed since the last run — perfect for release alerts, star-velocity tracking, and competitive intelligence on open-source projects.

If you care about GitHub monitoring, devtools competitive intel, dependency tracking, release notifications, or turning open-source activity into buying and growth signals, this actor is for you.

Why this actor is reliable

It talks only to the public GitHub REST API (api.github.com) — the same API GitHub officially documents and supports. Requests are simple JSON GETs with proper User-Agent and Accept headers. There are no CAPTCHAs, no WAFs, no IP blocks and no brittle HTML parsing. The anonymous rate limit is 60 requests/hour; add an optional GitHub token and it jumps to 5000 requests/hour. When the limit is reached, the actor reads GitHub's x-ratelimit-remaining / x-ratelimit-reset headers and stops politely — it never hammers the API and never charges you for a request that didn't return data.

	This GitHub Repo Monitor (REST API)	GitHub-trending / HTML scrapers	Watching repos by hand
Release tracking	✅ Per-repo, monitor mode	Rare	Manual
Star velocity (starsDelta)	✅ Computed each run	❌	❌
Issues / commits / contributors	✅ Selectable	Limited	Manual
Blocking / CAPTCHAs	❌ Official API	✅ Possible	—
Only NEW activity on later runs	✅	❌	—
Rate-limit handling	✅ Reads headers, stops politely	Varies	—

What you get for each item

A release:

{
  "repo": "apify/crawlee",
  "type": "release",
  "id": 178654321,
  "tagName": "v3.11.0",
  "name": "Crawlee 3.11",
  "publishedAt": "2026-06-20T10:00:00Z",
  "url": "https://github.com/apify/crawlee/releases/tag/v3.11.0",
  "isPrerelease": false,
  "isNew": true,
  "checkedAt": "2026-07-02T09:00:00Z"
}

A repo snapshot (stars/forks/etc., always emitted, with starsDelta vs. the previous run):

{
  "repo": "facebook/react",
  "type": "repo-snapshot",
  "stars": 231480,
  "forks": 47200,
  "openIssues": 980,
  "watchers": 6400,
  "language": "JavaScript",
  "pushedAt": "2026-07-01T18:22:10Z",
  "description": "The library for web and native user interfaces.",
  "url": "https://github.com/facebook/react",
  "starsDelta": 152,
  "checkedAt": "2026-07-02T09:00:00Z"
}

An issue:

{
  "repo": "facebook/react",
  "type": "issue",
  "number": 31245,
  "title": "Bug: hydration mismatch with Suspense",
  "state": "open",
  "author": "octocat",
  "createdAt": "2026-06-30T14:58:31Z",
  "url": "https://github.com/facebook/react/issues/31245",
  "isNew": true,
  "checkedAt": "2026-07-02T09:00:00Z"
}

Commits and contributors follow the same clean, flat shape.

How to use it

1. Add repositories — as owner/repo (e.g. facebook/react) or full GitHub URLs (e.g. https://github.com/apify/crawlee).
2. Pick what to track — releases, stars, issues, commits, contributors (default: releases + stars).
3. (Optional) Add a GitHub token — raises the rate limit from 60 to 5000 req/hr. It is stored as a secret.
4. (Optional) Enable monitor mode — and schedule the actor (e.g. hourly or daily). Each run returns only NEW activity per repo. Wire an Apify webhook to push new releases/issues straight to Slack, email, or your CRM.

Use cases

Each of these is a real search buyers make:

• "Get a Slack alert for new GitHub releases" — schedule the actor in monitor mode with a webhook so a new release in any tracked repo lands in Slack or email the moment it ships.
• "Track competitor OSS and star velocity" — monitor a rival's repos for releases, issue volume, contributor growth, and daily starsDelta as a live competitive-intel feed.
• "Monitor dependencies for new releases and security issues" — watch the repos behind your critical dependencies so upgrades and security-relevant issues are never a surprise.
• "Spot accelerating open-source projects for VC deal flow" — track daily star velocity across a watchlist to catch projects breaking out before the market notices.
• "Feed GitHub activity to an AI agent" — pipe releases and issues into an LLM workflow via the Apify MCP server.

Track competitor OSS & star velocity

The sharpest competitive-intel use: add a competitor's repositories, track stars + releases + issues in monitor mode, and every run gives you their release cadence, their issue backlog trend, and — via starsDelta — exactly how fast their community is growing day over day. It's a public, real-time read on a rival's open-source momentum.

Pricing

Pay per item delivered — no subscription, no minimum. You only pay for the releases, snapshots, issues, commits and contributors actually pushed to your dataset. Repos that 404 or fail are recorded in the run's key-value store and never charged.

FAQ

Which GitHub data can it track?

Five signals per repository: releases, stars (a full repo snapshot: stars, forks, open issues, watchers, language, last push, description, plus starsDelta), issues (pull requests excluded), commits, and contributors. Choose any combination in the track input.

How do I get Slack or Discord alerts for new GitHub releases?

Enable monitorMode, track releases, schedule the actor (e.g. hourly), and attach an Apify webhook or integration to the run. Each new release is pushed to Slack, Discord, email, or your CRM the moment it appears — a hosted alternative to polling the GitHub releases page yourself.

Do I need a GitHub token?

No. The actor works anonymously at GitHub's 60 requests/hour limit — enough to monitor a handful of repos. For larger watchlists or frequent scheduled runs, add a read-only personal access token to raise the limit to 5000 requests/hour. The token is stored as a secret input. See the GitHub REST API rate-limit docs.

How does monitor mode work?

With monitorMode enabled, the actor keeps a per-repo record of previously seen release/issue/commit/contributor IDs in a persistent named key-value store (GITHUB-MONITOR-STATE). On each run it compares current activity against that record and outputs only the new items (isNew: true). The first run for a repo is a baseline (it records what already exists and pushes nothing). Repo snapshots are always emitted and carry a starsDelta computed against the previous run.

What happens when the rate limit is hit?

The actor reads GitHub's x-ratelimit-remaining and x-ratelimit-reset headers. When the limit is exhausted it stops politely, records a RATE_LIMIT note (with the reset time and a hint to add a token) in the run's key-value store, and keeps every item already delivered. It never spins on a rate-limited API.

What happens if a repo doesn't exist?

A repository that returns 404 (typo, private, or deleted) is recorded in the FAILED record of the run's key-value store and in the run log, and you are never charged for it. The rest of your list continues processing normally.

Is this legal / allowed?

Yes. The actor reads the public, official GitHub REST API using a proper User-Agent and honoring GitHub's documented rate limits. No login is required for public repositories, no private data is accessed, and no rate-limit abuse occurs.

Can AI agents use this actor?

Absolutely. The input schema is flat and agent-friendly, and every Apify actor is consumable via the Apify MCP server, so AI agents and LLM pipelines can call this as a tool to monitor open-source repositories autonomously.