# GitHub Release Monitor & Dependency Alerts (`johnatan029/github-release-monitor`) Actor

Monitor GitHub repositories for genuinely new releases without duplicates. Get tags, release notes, prerelease flags, authors, assets, publish dates, and free repo metrics. Stateful baseline prevents repeat billing and supports scheduled dependency, DevOps, security, and changelog workflows.

- **URL**: https://apify.com/johnatan029/github-release-monitor.md
- **Developed by:** [Johnn Mottin](https://apify.com/johnatan029) (community)
- **Categories:** Developer tools, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $1.00 / 1,000 new releases

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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:

```text
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:

```text
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:

```text
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:

```text
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:

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

Repository metadata route:

```text
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:

```text
60 requests/hour
```

for unauthenticated requests.

With standard personal authentication, GitHub documents:

```text
5,000 requests/hour
```

for the primary REST API rate limit.

A normal successful repository currently requires approximately:

```text
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

```json
{
  "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:

```text
microsoft/vscode
```

or:

```text
https://github.com/microsoft/vscode
```

or:

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

The Actor normalizes valid values to:

```text
owner/repo
```

Duplicate repository entries are removed case-insensitively.

***

### Pre-release behavior

By default:

```json
{
  "includePrereleases": true
}
```

so a new GitHub release with:

```text
prerelease: true
```

can be emitted.

To exclude pre-releases:

```json
{
  "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:

```text
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

```json
{
  "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:

```text
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:

```text
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:

```text
404
```

the Actor writes a free summary such as:

```json
{
  "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:

```text
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:

```text
release ID: 12345
tag: v2.0.0
```

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

```text
12345
```

the Actor does not emit a second `NEW_RELEASE`.

***

### Draft releases

The Actor defensively excludes records marked:

```text
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:

```text
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:

```text
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:

```text
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

```json
{
  "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:

```bash
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:

```text
<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:

```text
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:

```text
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:

```text
REPO_SUMMARY
RUN_SUMMARY
```

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

***

### Cost control

The main output-cost control is:

```text
maxResults
```

Other controls affect the monitoring scope:

```text
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:

```text
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:

```text
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:

```json
{
  "includePrereleases": true
}
```

#### Can I ignore pre-releases?

Yes.

Set:

```json
{
  "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:

```text
body
```

when GitHub supplies them.

#### Does it return the release author?

Yes, through:

```text
authorLogin
```

when available.

#### Does it return attached assets?

It returns:

```text
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:

```text
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

# Actor input Schema

## `repos` (type: `array`):

owner/repo entries (e.g. microsoft/vscode). Private or missing repos come back as a controlled status, never crash the batch.

## `githubToken` (type: `string`):

Your own personal access token (classic or fine-grained, public repo read is enough). Raises the API rate limit from 60 to 5,000 requests/hour. Never logged, never stored in the dataset.

## `includePrereleases` (type: `boolean`):

When off, releases flagged prerelease by the API are not charged or written (they are still remembered, so turning this on later never re-bills history).

## `maxReleasesPerRepo` (type: `integer`):

Recent releases read per repo per run.

## `maxResults` (type: `integer`):

Hard cap on charged NEW\_RELEASE records. The run stops gracefully and keeps what it delivered.

## `maxRuntimeMs` (type: `integer`):

Hard time cap. The run also stops gracefully before exhausting the API rate limit.

## `debug` (type: `boolean`):

Log pacing waits and per-repo decisions. The token is never logged in any mode.

## Actor input object example

```json
{
  "repos": [
    "microsoft/vscode",
    "apify/crawlee"
  ],
  "includePrereleases": true,
  "maxReleasesPerRepo": 30,
  "maxResults": 200,
  "maxRuntimeMs": 300000,
  "debug": false
}
```

# Actor output Schema

## `results` (type: `string`):

Default dataset containing NEW\_RELEASE, REPO\_SUMMARY, and RUN\_SUMMARY records.

## `stats` (type: `string`):

STATS key-value-store record with billing, quality, request, retry, rate-limit, and run metrics.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "repos": [
        "microsoft/vscode",
        "apify/crawlee"
    ],
    "includePrereleases": true,
    "maxReleasesPerRepo": 30,
    "maxResults": 200,
    "maxRuntimeMs": 300000,
    "debug": false
};

// Run the Actor and wait for it to finish
const run = await client.actor("johnatan029/github-release-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "repos": [
        "microsoft/vscode",
        "apify/crawlee",
    ],
    "includePrereleases": True,
    "maxReleasesPerRepo": 30,
    "maxResults": 200,
    "maxRuntimeMs": 300000,
    "debug": False,
}

# Run the Actor and wait for it to finish
run = client.actor("johnatan029/github-release-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "repos": [
    "microsoft/vscode",
    "apify/crawlee"
  ],
  "includePrereleases": true,
  "maxReleasesPerRepo": 30,
  "maxResults": 200,
  "maxRuntimeMs": 300000,
  "debug": false
}' |
apify call johnatan029/github-release-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,johnatan029/github-release-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/biFzTp6Vpp8vKZ3Ma/builds/iuMoWV4E3yzdtY5XT/openapi.json