GitHub Release Monitor & Dependency Alerts

Monitor GitHub repositories and receive only releases you have not seen before.

This Actor is a stateful release monitor built on the official GitHub REST API. It creates a free baseline for each repository, remembers release IDs across runs, and then emits a billable NEW_RELEASE record only when GitHub publishes a genuinely unseen release.

It is designed for dependency monitoring, DevOps, security engineering, platform teams, release intelligence, developer relations, changelog workflows, and automated release alerts.

No browser scraping. No GitHub login required for public repositories. Optional personal access token for a higher API rate limit.

Key features

• Stateful GitHub release monitoring
• Persistent deduplication by GitHub release ID
• Free first-run baseline per repository
• Only genuinely new releases are billable
• Release tag and release name
• Full release notes/body when available
• Pre-release flag
• Release author
• Attached asset count
• Published and created timestamps
• Direct GitHub Release URL
• Optional pre-release exclusion
• Free repository metrics every run
• Stars, forks, open issues, subscribers, language, branch, pushed date
• Up to 100 repositories per run
• Optional GitHub personal access token
• Graceful API rate-limit protection
• Tasks and Schedules
• API, webhook, n8n, Make, Slack, database, and dashboard workflows
• Pay Per Event

Unofficial community Actor. Not affiliated with, sponsored by, or endorsed by GitHub, Inc. Data is obtained through the official GitHub REST API. Your GitHub token, when provided, is treated as a secret and is never written to the dataset or logs.

---

What this Actor is for

A normal release scraper can return the same releases every time it runs.

That is useful for extraction, but inefficient for monitoring.

This Actor is designed around a different question:

What did one of my monitored repositories release since I last checked?

The Actor stores release IDs in persistent state.

When a release has already been seen, it is not emitted again as a NEW_RELEASE.

This makes recurring schedules practical for:

• software dependency monitoring;
• platform engineering;
• DevOps;
• security update awareness;
• open-source ecosystem monitoring;
• internal changelog feeds;
• release intelligence;
• developer relations;
• product/competitive research around open-source tools;
• Slack, Teams, Discord, or email alert workflows;
• automated release-note pipelines.

---

Important: the first run is a free baseline

The first time the Actor sees a repository, it learns the recent release IDs.

It does not emit those existing releases as new.

Example:

First run:
30 releases fetched
30 release IDs remembered
0 NEW_RELEASE records
0 historical releases charged

If the repository publishes a new release after that:

Second run:
31 recent releases visible
30 already known
1 genuinely new release
1 NEW_RELEASE record

This avoids turning historical data into false alerts.

---

Important: deduplication uses GitHub release.id

The persistent identity for an event is GitHub's release ID.

That means an edited release is not treated as a new release merely because:

• its title changed;
• the release notes changed;
• an asset was added;
• metadata was edited.

If the release keeps the same GitHub release ID, it remains already seen.

The Actor is intentionally a new-release monitor, not an edit monitor.

---

Who it's for

Platform and DevOps teams

Monitor upstream dependencies and infrastructure projects.

Examples:

kubernetes/kubernetes
microsoft/vscode
nodejs/node
apify/crawlee

Feed new releases into:

• Slack;
• an internal dependency dashboard;
• incident/change-management workflows;
• release review queues;
• automation systems.

---

Security and dependency teams

Use release events as one input into dependency awareness.

The Actor does not classify a release as:

safe
unsafe
vulnerable
breaking

by itself.

It supplies the release data.

Your downstream workflow can then:

• inspect release notes;
• match dependency inventories;
• create review tasks;
• pass notes to a vulnerability or AI analysis step;
• notify the responsible team.

---

Developer relations and ecosystem teams

Monitor projects in an ecosystem and follow:

• product releases;
• pre-releases;
• release cadence;
• release notes;
• repository activity metrics.

---

Research and competitive intelligence teams

Watch public software projects without manually revisiting GitHub release pages.

---

Automation builders

Use clean release events as input for:

• n8n;
• Make;
• Zapier;
• webhooks;
• Slack;
• Microsoft Teams;
• Discord;
• email workflows;
• databases;
• dashboards;
• AI agents;
• internal applications.

---

How it works

For each repository, the Actor:

1. validates and normalizes the repository name;
2. checks the currently tracked GitHub API quota;
3. fetches recent releases from the official GitHub REST API;
4. normalizes the release fields;
5. loads persistent release-ID state for that repository;
6. compares fetched release IDs with previously seen IDs;
7. remembers all valid seen release IDs;
8. emits only genuinely unseen qualifying releases;
9. fetches native repository metadata for a free summary;
10. writes a free REPO_SUMMARY;
11. writes a free RUN_SUMMARY when the run finishes.

The Actor processes repositories with controlled pacing and retry behavior.

---

Data source

The Actor uses the official GitHub REST API.

Primary release route:

GET /repos/{owner}/{repo}/releases

Repository metadata route:

GET /repos/{owner}/{repo}

The Actor does not scrape GitHub HTML pages.

---

GitHub API rate limits

For standard REST API usage, GitHub documents a primary limit of:

60 requests/hour

for unauthenticated requests.

With standard personal authentication, GitHub documents:

5,000 requests/hour

for the primary REST API rate limit.

A normal successful repository currently requires approximately:

1 request for releases
1 request for repository metadata

so anonymous monitoring is best for smaller lists.

For larger portfolios, provide your own token.

The Actor tracks rate-limit response headers and stops gracefully before the remaining request budget is exhausted.

---

GitHub token privacy

githubToken is optional.

When provided:

• it is passed only inside the GitHub client request layer;
• it is not written to dataset records;
• it is not included in run summaries;
• it is not deliberately written to logs;
• errors defensively redact bearer material.

The token field is marked secret in the Apify input schema.

For public repositories, use the minimum permissions appropriate for your GitHub account and workflow.

Private repositories are visible only when GitHub allows the supplied credentials to access them.

If GitHub returns 404, the Actor treats the repository as unavailable/not found instead of crashing the entire batch.

---

Input

Recommended example

{
  "repos": [
    "microsoft/vscode",
    "apify/crawlee",
    "nodejs/node"
  ],
  "includePrereleases": true,
  "maxReleasesPerRepo": 30,
  "maxResults": 200,
  "maxRuntimeMs": 300000
}

Input fields

Field	Default	Description
repos	required	GitHub repositories in owner/repo format. GitHub URLs are also normalized. Maximum 100 input entries.
githubToken	empty	Optional secret personal access token for authenticated API requests.
includePrereleases	true	Whether unseen releases marked prerelease can be written as NEW_RELEASE.
maxReleasesPerRepo	30	Recent releases fetched per repository. Range: 5–100.
maxResults	200	Hard cap on billable NEW_RELEASE records. Range: 1–2,000.
maxRuntimeMs	300000	Hard runtime cap in milliseconds. Range: 10,000–3,600,000.
debug	false	Enables additional diagnostic logs.

---

Repository formats

You can use:

microsoft/vscode

or:

https://github.com/microsoft/vscode

or:

https://github.com/microsoft/vscode.git

The Actor normalizes valid values to:

owner/repo

Duplicate repository entries are removed case-insensitively.

---

Pre-release behavior

By default:

{
  "includePrereleases": true
}

so a new GitHub release with:

prerelease: true

can be emitted.

To exclude pre-releases:

{
  "includePrereleases": false
}

Important billing behavior

Even when a pre-release is excluded, its release ID is still remembered.

That means:

1. pre-release v2.0.0-beta.1 appears;
2. includePrereleases is false;
3. it is not written or charged;
4. you later change the option to true;
5. the old pre-release is still considered already seen.

This prevents configuration changes from re-billing historical releases.

---

Output

The default dataset can contain three record types:

NEW_RELEASE
REPO_SUMMARY
RUN_SUMMARY

---

NEW_RELEASE

This is the billable release-event record.

It is written only when:

• the repository is not in baseline mode;
• the GitHub release ID has not been seen before;
• the release is not a draft;
• the pre-release setting allows it;
• user/platform caps allow the record to be delivered.

Example

{
  "recordType": "NEW_RELEASE",
  "entityId": "listening:github:owner/example/release/123456789",
  "source": "github",
  "repo": "owner/example",
  "releaseId": "123456789",
  "tagName": "v2.4.0",
  "name": "Version 2.4.0",
  "prerelease": false,
  "htmlUrl": "https://github.com/owner/example/releases/tag/v2.4.0",
  "publishedAt": "2026-08-25T15:30:00Z",
  "createdAt": "2026-08-25T14:55:00Z",
  "authorLogin": "maintainer",
  "assetCount": 4,
  "body": "Highlights, fixes, migration notes...",
  "observedAt": "2026-08-26T12:00:00.000Z"
}

---

NEW_RELEASE fields

Field	Description
recordType	NEW_RELEASE.
entityId	Stable JM Forge event identity.
source	github.
repo	Repository in owner/repo format.
releaseId	GitHub release ID used for persistent deduplication.
tagName	GitHub release tag.
name	Release name when available.
prerelease	GitHub prerelease flag.
htmlUrl	Public release page URL.
publishedAt	GitHub publication timestamp.
createdAt	GitHub release creation timestamp.
authorLogin	Release author login when available.
assetCount	Number of attached release assets.
body	Release body/notes when available.
observedAt	Timestamp when the Actor observed the release.

---

REPO_SUMMARY

A free repository-level summary is written for processed repositories.

For a normal successful repository it can include:

repo
status
baseline
releasesFetched
newReleases
releasesDelivered
seenBefore
prereleasesExcluded
latestTag
latestPublishedAt
native
observedAt

---

Native repository metrics

The native block comes from the GitHub repository API and can include:

fullName
description
stargazersCount
forksCount
openIssuesCount
subscribersCount
language
pushedAt
defaultBranch
archived

These metrics are included in the free repository summary.

The Actor does not invent engagement or popularity scores.

---

Missing or inaccessible repositories

If GitHub returns:

404

the Actor writes a free summary such as:

{
  "recordType": "REPO_SUMMARY",
  "repo": "owner/missing-or-private",
  "status": "NOT_FOUND",
  "observedAt": "2026-08-26T12:00:00.000Z"
}

This condition does not automatically crash the entire repository batch.

---

RUN_SUMMARY

A free final run summary is written even when there are no new release events.

It provides visibility into:

• billable records;
• free records;
• baseline repositories;
• repositories not found;
• repositories completed;
• repositories failed;
• rate-limit totals;
• requests remaining;
• rate-limit stops;
• HTTP requests;
• HTTP retries;
• cap reason;
• source availability;
• quality warnings;
• operational cost metrics.

This also ensures a successful no-change run still has visible output.

---

Stateful deduplication

Each repository has persistent state containing recently seen release IDs.

The current implementation keeps up to:

2,000 release IDs per repository

in its bounded state.

GitHub releases are normally infrequent enough that this represents a long monitoring history for typical projects.

---

Release edits

This Actor does not create a new event when an existing GitHub Release is edited.

Example:

release ID: 12345
tag: v2.0.0

If the maintainer edits its body tomorrow but the release ID remains:

12345

the Actor does not emit a second NEW_RELEASE.

---

Draft releases

The Actor defensively excludes records marked:

draft: true

from event generation.

Draft visibility depends on GitHub permissions and API behavior.

The product promise is monitoring releases visible through the API under the credentials supplied by the user.

---

Rate-limit protection

The Actor tracks:

X-RateLimit-Remaining
X-RateLimit-Limit
X-RateLimit-Reset

from GitHub API responses.

When the remaining request count reaches the internal safety threshold, later repositories are skipped gracefully and:

capReason: RATE_LIMIT

can be recorded.

The Actor does not intentionally continue making requests until GitHub rejects the run for quota exhaustion.

---

Retry behavior

Retryable conditions can include:

• transient network failures;
• timeouts;
• GitHub 429;
• applicable 5xx responses.

The client uses controlled retry delays and jitter.

Non-retryable or exhausted conditions become controlled run/repository errors instead of silently producing fabricated release records.

---

Scheduling

This Actor is designed for recurring execution.

Recommended cadences depend on how quickly you need release awareness.

Typical choices:

every few hours
daily

Releases are discrete events and persistent deduplication makes overlapping monitoring windows safe.

---

Recommended scheduled workflow

1. Add your repository list.
2. Run once to create the baseline.
3. Save the configuration as an Apify Task.
4. Go to Console → Schedules → Create schedule.
5. Choose the cadence.
6. Send future NEW_RELEASE records downstream.

Possible destinations:

• Slack;
• Teams;
• Discord;
• email workflows;
• n8n;
• Make;
• Zapier;
• webhook;
• database;
• dashboard;
• issue/ticket system;
• internal application.

---

Example dependency-monitoring workflow

Input

{
  "repos": [
    "nodejs/node",
    "microsoft/TypeScript",
    "apify/crawlee"
  ],
  "includePrereleases": false,
  "maxReleasesPerRepo": 30,
  "maxResults": 100
}

Workflow

1. First run establishes a baseline.
2. A Schedule runs the Task every morning.
3. The Actor checks the latest GitHub Releases.
4. Already-seen release IDs are ignored.
5. Genuinely new releases are written as NEW_RELEASE.
6. A downstream workflow can:
   • send release notes to Slack;
   • open an internal review ticket;
   • match the repo against an inventory;
   • ask an AI agent to summarize changes;
   • flag migration notes;
   • update a dependency dashboard.

The Actor supplies deterministic release events.

The downstream workflow decides the business action.

---

API

Run the Actor through the Apify API and retrieve the dataset programmatically.

Example:

curl -s "https://api.apify.com/v2/acts/<YOUR_USERNAME>~github-release-monitor/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "repos":["microsoft/vscode","apify/crawlee"],
    "includePrereleases":true,
    "maxReleasesPerRepo":30,
    "maxResults":200
  }'

Replace:

<YOUR_USERNAME>
<YOUR_APIFY_TOKEN>

with your Apify account values.

If you also want authenticated GitHub requests, place your GitHub token in the Actor input field:

githubToken

not in the Apify API URL.

---

Integrations

The Actor works with:

• Apify API;
• Apify Tasks;
• Apify Schedules;
• webhooks;
• n8n;
• Make;
• Zapier;
• Slack;
• Microsoft Teams;
• Discord;
• Google Sheets;
• databases;
• BI tools;
• AI agents;
• custom applications.

---

Pricing

This Actor uses Pay Per Event.

Two custom billing events are used by the code:

actor-start
new-release

actor-start

Charged once after valid input has been accepted.

Invalid input is rejected before the start charge is opened.

new-release

Charged for each delivered NEW_RELEASE record.

The following are not billable release events:

• baseline history;
• already-seen releases;
• edited releases with the same release ID;
• excluded pre-releases;
• REPO_SUMMARY;
• RUN_SUMMARY;
• repositories returning NOT_FOUND.

The Pricing tab on the Actor page is always the authoritative source for current prices.

---

What is free

These records are designed to be free:

REPO_SUMMARY
RUN_SUMMARY

The initial repository baseline also does not emit historical NEW_RELEASE records.

---

Cost control

The main output-cost control is:

maxResults

Other controls affect the monitoring scope:

repos
includePrereleases
maxReleasesPerRepo
maxRuntimeMs

Lower-cost / focused monitoring

Use:

• fewer repositories;
• pre-releases disabled if you do not need them;
• a practical release-fetch window;
• a smaller maxResults.

Larger portfolios

Use your GitHub token to avoid the small unauthenticated API ceiling.

---

Run health

Operational statistics are persisted in:

STATS

in the default key-value store.

Depending on the run, statistics can include:

• requests;
• retries;
• API-rate-limit numbers;
• repositories completed;
• repositories failed;
• repositories not found;
• baseline repositories;
• charged records;
• free records;
• quality alerts;
• warnings;
• source-unavailable state;
• runtime;
• cost estimates.

---

Controlled errors

The Actor uses stable/controlled errors for important conditions.

Examples can include:

INVALID_INPUT
HTTP_TIMEOUT
HTTP_UNAVAILABLE
HTTP_RATE_LIMITED
API_CONTRACT_CHANGED
ALL_UNITS_FAILED

A failure in one repository does not automatically make every other repository fail.

---

Honest limits

GitHub Releases only

The Actor monitors the GitHub Releases API.

A repository that publishes only bare Git tags without creating GitHub Releases is outside the current event contract.

---

First run does not backfill alerts

Historical releases are deliberately learned as baseline rather than emitted as new.

If you need a historical export, this Actor is not designed as a backfill scraper.

---

Release edits are not events

Changing release notes on an existing release does not create a new NEW_RELEASE.

---

Pre-releases can be excluded, but they remain remembered

This prevents configuration changes from billing old pre-release history.

---

API quota applies

Anonymous API requests have a much smaller primary rate limit than authenticated requests.

Large repository portfolios should use a GitHub token.

---

Private repositories depend on token access

A private repository can only be read when GitHub grants the supplied credentials access.

Otherwise GitHub can return 404.

---

No security classification

The Actor does not claim a release is:

• vulnerable;
• patched;
• breaking;
• safe;
• critical.

Those judgments require downstream context.

---

No AI in runtime

Release fields and native repository metrics come from GitHub API data and deterministic Actor logic.

The Actor does not generate an AI summary of the release notes.

---

Source behavior can change

GitHub can change API behavior, response contracts, or limits.

The Actor includes explicit error and quality handling to surface unexpected changes instead of inventing data.

---

FAQ

Do I need a GitHub account?

No, for public repository monitoring within the unauthenticated API limit.

Do I need a GitHub token?

No for small public-repository lists.

A token is strongly recommended for larger portfolios.

What rate limit do I get without a token?

GitHub currently documents 60 unauthenticated REST API requests per hour.

What rate limit do I get with a normal personal token?

GitHub currently documents a 5,000-request/hour primary REST API limit for standard authenticated personal requests.

Does the Actor store my GitHub token?

It is not deliberately stored in the dataset, summaries, or logs.

What happens on the first run?

The Actor creates a baseline and does not emit historical releases as NEW_RELEASE.

Why did I get only REPO_SUMMARY and RUN_SUMMARY?

Most likely because:

• this was the baseline run; or
• no genuinely new releases appeared.

That is a valid monitoring result.

Can I receive pre-releases?

Yes.

Keep:

{
  "includePrereleases": true
}

Can I ignore pre-releases?

Yes.

Set:

{
  "includePrereleases": false
}

If I later enable pre-releases, will old ones be charged?

No.

Excluded pre-release IDs are still remembered.

Does editing a release trigger a new event?

No.

Deduplication uses GitHub release ID.

Does a new Git tag trigger an event?

Only if it is represented as a GitHub Release returned by the Releases API.

Bare tag-only events are not part of v1.

Does the Actor return release notes?

Yes, in:

body

when GitHub supplies them.

Does it return the release author?

Yes, through:

authorLogin

when available.

Does it return attached assets?

It returns:

assetCount

not full downloaded asset files.

Does it return repository stars and forks?

The free REPO_SUMMARY.native block can include GitHub's native repository metrics such as stars and forks.

Can I monitor 100 repositories?

The input contract accepts up to 100 repositories.

Without authentication, the GitHub API rate limit will normally stop a large list early.

Use a token for larger portfolios.

What happens when API quota is running low?

The Actor stops later repository work gracefully before the tracked remaining quota is exhausted.

What am I charged for?

The custom start event shown in Pricing plus genuinely new NEW_RELEASE records delivered according to the Pay Per Event configuration.

Are baseline releases charged?

No.

Are repository summaries charged?

No.

Is the final run summary charged?

No.

Is this affiliated with GitHub?

No.

This is an unofficial community Actor and is not affiliated with, sponsored by, or endorsed by GitHub, Inc.

---

Support

For questions, bugs, or requested fields:

johnatan291303@gmail.com

You can also use the Issues section on the Actor page.

---

Part of the JM Forge suite

Also from the same developer:

• Company Tech Stack Monitor — monitor public technology-stack change events.
• Shopify Price & Catalog Monitor — persistent price, stock, product-added, and product-removed change events.
• Shopify Competitor Sale & New Arrival Insights — current Shopify sale and new-arrival intelligence.
• ATS Hiring Signals Monitor — structured public hiring signals from supported applicant-tracking systems.

JM Forge Actors are built as independent tools for data intelligence, monitoring, researc