Changelog & Release Notes Watcher: GitHub Releases, CHANGELOG.md, RSS

Watch the projects you depend on and get one structured item per version: the version, a parsed SemVer, the release date, the title, the release notes as Markdown, a link, and flags for breaking changes and security fixes (with the CVE and GHSA ids the notes mention).

Run it once to see the latest releases of each source, or put it on a schedule with Only report versions that are new since the last run ticked, and it reports only the versions that are new since the previous run, ready for a webhook, a Slack integration, a dataset export or an AI agent.

It reads four kinds of public source:

• GitHub repositories (owner/repo): Releases, through the official GitHub REST API. Repositories without releases fall back to their tags.
• Changelog files: CHANGELOG.md, HISTORY.md, CHANGES.rst and similar, as raw files or GitHub file links (only the file you name is read).
• RSS and Atom feeds of releases or product updates.
• HTML release-notes pages that are rendered on the server.

Built and maintained by Lathesmith with AI assistance.

Who it is for

• Engineering teams who want a daily or weekly "what changed in our dependencies" feed in Slack, email or a ticket queue, including dependencies that publish a changelog page instead of GitHub releases.
• Security and platform teams who want to know when a release mentions a CVE or a security fix, as data (security, cveIds, ghsaIds) rather than as an email to read.
• Developer-relations and product people tracking competitors' or partners' public changelogs.
• AI agents and RAG pipelines that need "what is new in X since last week?" as a tool call, with notes already in Markdown.

How to use it

One look at the latest releases

1. Enter your Sources, one per line, for example nodejs/node, microsoft/TypeScript, https://github.com/expressjs/express/blob/master/History.md, https://nodejs.org/en/feed/releases.xml.
2. Run it. The dataset has the latest 3 versions of each source (change this with Versions per source on a first look).

A watch list on a schedule (only what is new)

Tick Only report versions that are new since the last run and schedule the run; see Running on a schedule below.

Input

Field	Default	What it does
sources	required	Up to 200 sources: owner/repo, GitHub repository/releases/file links, raw changelog URLs, feed URLs, release-notes page URLs.
onlyNewVersions	false (unticked)	"Only report versions that are new since the last run (for scheduled runs)". Off: every run reports the latest versions of each source, and nothing is remembered. On: the first run reports the latest versions as a starting point and later runs report only versions not reported before.
stateKey	empty	Optional name for that memory (one per watch list). Empty: chosen automatically when onlyNewVersions is on. Setting a key also turns onlyNewVersions on, as in earlier versions.
firstRunItems	3	Versions reported for a source seen for the first time (1 to 50). While memory between runs is off (onlyNewVersions unticked and no stateKey), every run reports this many.
maxNewItemsPerSource	20	Most new versions reported for one source in one run; the newest are kept (1 to 100).
resetState	false	"Start over": forget the remembered versions of these sources and report their latest versions again. Switch it off after that run: while it is on, every run starts over.
includePrereleases	true	Report alpha, beta, rc and other pre-releases. Every item has a prerelease flag either way.
maxNotesChars	125,000	Longest release notes kept per version (0 to 500,000; 0 leaves notes out). The default fits any GitHub release.
githubToken	none	Optional, stored encrypted. Gives higher GitHub API limits: 5,000 requests per hour for you instead of 60 per hour shared with everyone on the same IP address; GitHub-hosted changelog files are then read through the API too. Free to create in about 2 minutes (below). Sent only to api.github.com, in the Authorization header.
githubTagsFallback	true	When a repository has no releases, report its git tags instead.
requestsPerMinutePerHost	60	Politeness limit for any one website (6 to 120).

Yes/no fields take true or false. From the API, "true"/"false" and 1/0 are accepted with a warning; any other value is reported in the log and in OUTPUT.warnings, and the default is used.

GitHub token (optional)

Without a token, GitHub allows 60 API requests per hour per IP address, and Apify's addresses are shared with other users, so busy hours can use that up; GitHub repositories beyond the limit are skipped and not charged (changelog files hosted on GitHub are downloaded without the API when there is no token, so they are not affected). A token raises the limit to 5,000 per hour for you. To create a free, read-only one (about 2 minutes):

1. On GitHub, open Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token (or go straight to github.com/settings/personal-access-tokens/new).
2. Enter a name (for example "Changelog Watcher") and an expiry date.
3. Under Repository access, choose Public repositories (read-only).
4. Add no permissions. Click Generate token, copy it and paste it into GitHub token.

The token is stored encrypted by Apify, sent only to api.github.com in the Authorization header, and never logged or written to the outputs. If GitHub rejects it (mistyped, expired or revoked), the run says so once, in the log and in OUTPUT.warnings; changelog files hosted on GitHub are then downloaded as without a token, and GitHub repositories are skipped (not charged). You can revoke it on the same GitHub page at any time.

Running on a schedule

1. Enter your sources and tick Only report versions that are new since the last run. Optionally give a State key (for example my-dependencies), one per watch list.
2. Save the input as a task and run it once: it reports the latest versions of each source (marked "event": "baseline") and remembers them, in a key-value store named lathesmith-changelog-watcher-state in your own Apify account.
3. Add a schedule to the task (daily or weekly is typical). Each later run reports only versions it has not reported before (marked "event": "new"). Runs where nothing changed produce an empty dataset and a DIGEST.md that says "No new versions".
4. Connect the dataset or the DIGEST.md record to Slack, email, a webhook or your own code with Apify's integrations, for example to notify you only when the dataset is not empty.

Good to know:

• The memory is off by default. With the box unticked, nothing is remembered and every run reports the latest versions of each source (firstRunItems per source), so a schedule would send the same versions every time.
• Automatic state key. If you tick the box and leave the state key empty, a run from a saved task uses one key per task (task-…); it stays the same when you edit the task's sources (new sources start with a baseline, the others carry on). A run without a task (from the API, or from an AI agent) uses one key per list of sources (list-…): the same list in any order keeps its memory, but a different list starts over and reports the latest versions of every source again. Set your own state key to avoid that. The key used is shown in the log and in OUTPUT.stateKey. Automatic keys are listed in a small index record (_automatic-keys) in the same store, and the memory under an automatic key is deleted during a later run that also uses an automatic key, once no run has used it for 180 days (OUTPUT.expiredStateKeysDeleted lists what that run deleted; nothing is deleted while no such run happens); keys you set yourself are never deleted.
• Use a different state key for each watch list, and do not start two runs with the same key at the same time (both could report the same versions).
• To start a watch list over, run it once with Start over switched on, then switch it off again.
• Inputs from earlier versions that set only a state key keep working: a state key turns the option on.

Minimal input for a scheduled watch list:

{
    "sources": ["nodejs/node", "microsoft/TypeScript", "https://raw.githubusercontent.com/olivierlacan/keep-a-changelog/main/CHANGELOG.md"],
    "onlyNewVersions": true,
    "stateKey": "my-dependencies"
}

Output

Dataset: one item per version

{
    "source": "https://raw.githubusercontent.com/olivierlacan/keep-a-changelog/main/CHANGELOG.md",
    "sourceType": "changelog-file",
    "sourceUrl": "https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md",
    "event": "new",
    "eventId": "dee75f4ae5a14e12",
    "version": "2.0.0",
    "semver": { "major": 2, "minor": 0, "patch": 0, "prerelease": null, "build": null, "normalized": "2.0.0", "strict": true },
    "date": "2026-06-07",
    "title": "2.0.0 - 2026-06-07",
    "notesMarkdown": "2.0.0 is the first major revision of Keep a Changelog. ...\n\n### Removed\n\n- ...",
    "notesTruncated": false,
    "sections": ["Removed", "Changed", "Added"],
    "url": "https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md#200---2026-06-07",
    "compareUrl": "https://github.com/olivierlacan/keep-a-changelog/compare/v1.1.2...v2.0.0",
    "breaking": true,
    "security": false,
    "cveIds": [],
    "ghsaIds": [],
    "prerelease": false,
    "yanked": false,
    "checkedAt": "2026-10-11T22:15:52.166Z"
}

• event is "new" for a version not reported before (with Only report versions that are new on), and "baseline" for the first look at a source (or on every run, while that option is off).
• eventId is stable for a source and version across runs; use it to de-duplicate downstream.
• date is a timestamp for GitHub releases and feeds, and a date (or a month, "2026-03") for changelog headings. It is null when the source gives none.
• url points at the release itself: the GitHub release page, the entry's anchor in the changelog, or the feed entry's link.
• breaking and security are set only when the text says so: a "BREAKING CHANGES" or "Security" section, feat!:-style commits, (SEMVER-MAJOR) labels, "backwards-incompatible", "security fix/release/update", "vulnerability", or a CVE/GHSA id. They are not guessed from the version number, and wording in documentation or tooling commits ("docs: update the security release process") does not count.

Key-value store

Record	Content
OUTPUT	Run summary: whether only new versions were reported and under which state key (onlyNewVersions, stateKey, stateKeyOrigin, and any old automatic keys deleted, expiredStateKeysDeleted); warnings about the input or the run (warnings, for example a rejected GitHub token); sources checked, unchanged (HTTP 304), failed, skipped and without versions; new and baseline versions; per-source status with the latest version and any error in plain English; why the run stopped early, if it did (stopReason), and how many sources timed out or hit a hard limit (limits); GitHub API rate-limit status; robots.txt status per site; memory use; which events were charged.
DIGEST.md	A short Markdown report of the run, grouped by source, with BREAKING and SECURITY tags and CVE ids. Handy for email or chat integrations.

Example DIGEST.md:

# Changelog digest, 2026-10-12

2 new version(s) since the last run (state "my-dependencies"), 0 reported as the first look at a source. 3 of 3 source(s) checked.

## nodejs/node

- [v26.11.1: 2026-10-07, Version 26.11.1 (Current), @aduh95](https://github.com/nodejs/node/releases/tag/v26.11.1) (2026-10-07)

## microsoft/TypeScript

No new versions. Latest: vscode-typescript/v1.0.1 (2026-09-30).

## https://raw.githubusercontent.com/vitejs/vite/main/packages/vite/CHANGELOG.md

- [8.3.4 (2026-10-08)](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#834-2026-10-08) (2026-10-08)

Supported sources and formats

Source	How to give it	How it is read
GitHub Releases	owner/repo, https://github.com/owner/repo, .../releases, .../releases.atom	GitHub REST API (api.github.com), one request per repository. Drafts are skipped; the pre-release flag comes from GitHub.
GitHub tags	as above, when a repository has no releases	GitHub REST API, one more request. Tags have no notes or dates.
Changelog files	raw URL, or a GitHub file link (.../blob/main/CHANGELOG.md); a file hosted on GitHub is read through the GitHub API when you give a token, otherwise downloaded from raw.githubusercontent.com (see Data sources and terms)	Markdown and reStructuredText headings: Keep a Changelog, conventional-changelog / release-please / standard-version, Changesets (also monorepo pkg@1.2.3), History.md style (1.2.3 / 2024-05-01 underlined), Python-style CHANGES.rst, Node.js-style (2025-09-25, Version 24.9.0), dated logs (## 2024-05-01, ## March 2024), and plain version lines (v9.0.0 - April 5, 2024). "Unreleased" sections are skipped.
Feeds	RSS 2.0, RSS 1.0 (RDF) or Atom URL	Each entry is a version when its title or link carries one (Announcing Rust 1.90.0, /releases/tag/v1.2.3), otherwise a dated entry. HTML content becomes Markdown.
Release-notes pages	page URL	The main content (navigation, sidebars, headers and footers removed) is converted to Markdown, then read like a changelog file. Heading ids become entry links.

How pages are fetched

• GitHub repositories are read only through GitHub's official REST API. The Actor never fetches github.com web pages or feeds, not even behind a redirect (github.com's robots.txt disallows its .atom feeds, and GitHub's terms restrict scraping). A changelog file hosted on GitHub is read through the API's contents endpoint when you give a token; without one, only that file is downloaded from raw.githubusercontent.com.
• Everything else goes through robots.txt, on every redirect too. Disallowed URLs are not fetched. A Crawl-delay of up to 60 seconds is honoured: requests to that site wait their turn. Sites asking for more than 60 seconds between requests are skipped. If a site's robots.txt cannot be read (a server error), nothing on that site is fetched, as RFC 9309 requires; nor is anything on a site whose robots.txt has wildcard rules far larger than any real site needs (over 32 KB of them).
• Polite by default: one request per second to any one site (configurable down to one every 10 seconds), a server's Retry-After is honoured, and conditional requests (ETag, Last-Modified) mean that unchanged sources on a schedule are usually answered with a short "304 Not Modified".
• Honest identity: the User-Agent is Mozilla/5.0 (compatible; LathesmithChangelogWatcher/0.1; Apify Actor by Lathesmith; +https://apify.com/store). Site owners can address LathesmithChangelogWatcher in robots.txt.
• No logins, cookies, proxies or bot-evasion. No browser is run, so pages that build their content with JavaScript come back empty (reported as "no versions found" and not charged); the project's CHANGELOG file or feed usually works instead.
• Public addresses only. URLs that point at private, loopback or cloud-metadata addresses are refused, on every redirect too, and the address is checked again at the moment of connecting, so a name that changes its answer (DNS rebinding) cannot reach them either.

Data sources and terms

• GitHub Releases and tags: GitHub's REST API (api.github.com), used under GitHub's API terms, within its rate limits (60 requests per hour per IP address without a token, 5,000 per hour with yours).
• Changelog files hosted on GitHub: with your token, through the same API's contents endpoint (raw file media type, one request per file); the token goes only to api.github.com, in the Authorization header. When the API cannot give the file (for example the token is rejected, an API limit is reached, GitHub answers with an error or not in time, or it cannot tell the branch from the path, as with branch names that contain /), the same file is downloaded as without a token. A link to a directory or a submodule fails with "not a file" (not charged). Without a token, only the files you list are downloaded from raw.githubusercontent.com, GitHub's file download host: one request per file per run, plus that host's robots.txt once per run, checked before any download; at the per-site rate limit (one request per second by default), with the honest User-Agent above. No crawling: links inside the file are never followed, and nothing else on GitHub is fetched.
• github.com web pages and feeds: never fetched.
• Every other site: only the URLs you list, under that site's robots.txt and the politeness limits above.
• Your part: release notes belong to their authors. Use this Actor for public sources you are allowed to read and process, and comply with each site's terms; the Actor only helps you stay within robots.txt and polite rate limits.

Pricing

This Actor uses pay-per-event pricing with two events:

• Run start: charged once per run, together with the first source that is checked successfully. A run in which every source fails costs nothing.
• Source checked: charged once for each source that was checked successfully: it was fetched and its versions were read, or it was unchanged since the last run (HTTP 304).

Not charged: sources that fail (network errors, HTTP errors, robots.txt disallows them, GitHub's rate limit is reached, the page is too large or has no versions) and sources skipped because the run stopped early. The number of versions reported does not change the price: a first run that reports 50 versions of a source costs the same as a run that finds nothing new. The current prices are shown in the Pricing tab; a run checking 20 sources costs one run-start fee plus 20 source-checked fees, and nothing else (the Actor's compute is included).

Set a maximum total charge on the run if you want a hard ceiling: the Actor checks only as many sources as it covers and says so in the log.

Limits and behaviour

• Up to 200 sources per run. Sources on different sites are checked in parallel; sources on the same site, one at a time at that site's pace. Each source gets at most 3 minutes. If the first 20 sources all fail, the run stops early (nothing is charged), because the input is probably wrong. The run also stops once 20 sources have timed out or hit a hard limit, even if other sources succeeded: a server that does not answer within 20 seconds (3 tries), the 3 minutes per source, or the time or memory limit for one document (below). A normal watch list has a few of these at most; HTTP errors and unknown host names fail at once and do not count. Either way, the sources not yet checked are skipped and not charged, the outputs and the state are saved for what was checked, OUTPUT.stopReason says why and OUTPUT.limits counts the sources that timed out or hit a limit.
• GitHub without a token allows 60 API requests per hour per IP address, and Apify's IP addresses are shared with other users. When the limit is reached, the remaining GitHub repositories are skipped (not charged) and OUTPUT.github says when it resets; changelog files hosted on GitHub do not use the API without a token, so they are not affected. For more than a handful of repositories, or hourly schedules, add a token (see GitHub token).
• What counts as "new": per source, the newest 100 versions of a changelog, feed or page (30 releases from the GitHub API, or more when firstRunItems asks for more) are compared with what was remembered under the state key; at most 300 versions per source are remembered. A version missing from that window (for example, more than 30 GitHub releases between two runs) is not reported. Backports that appear below newer versions are reported.
• GitHub tags are listed by name, not by date. For repositories with more than 100 tags the newest may be missing; use the project's changelog or release-notes page instead.
• Delivery is at-least-once. The state is saved after a source's versions are stored, and also every minute during the run, so if a run is interrupted, the next run reports at most the last minute's versions again rather than missing them. If the platform moves a run to another server, the run resumes without checking or charging the sources it had already delivered. Two runs with the same state key at the same time can each report the same versions; give concurrent watch lists different keys.
• Size limits: changelog files up to 8 MB. HTML pages up to about 1.6 MB at the default 512 MB of memory (about 3.3 MB at 1 GB), and feeds up to twice that. Documents are parsed in a separate worker thread with its own memory limit and a 60-second time limit: a document that needs more memory or time than that, or is nested more than 600 elements deep, is skipped and not charged, and the run carries on (until 20 sources have timed out or hit such a limit; see above).
• Memory and time: the Actor needs at least 512 MB of memory, which is also the default; typical runs peak at about 150-250 MB. Lists of many multi-megabyte documents come close to the limit at 512 MB (the 200-source heavy test list usually completes, but sometimes stops early on the memory guard; see the performance table), so give them 1 GB; HTML pages over about 1.6 MB also need 1 GB (see the size limits above). The default run timeout is 30 minutes, far more than typical watch lists need; raise it in the run options for very long lists of slow sites. If memory or the run's timeout gets close, it stops checking new sources, saves the state and writes OUTPUT and DIGEST.md for what was checked, and OUTPUT.stopReason says why. Skipped sources are not charged.
• Parsing is heuristic. Version headings are recognised by their shape; unusual layouts can be missed (reported as "no versions found", not charged) or, rarely, split differently from what a human would do. Report such sources in the Issues tab.
• Edits to old releases are not reported as new versions; a version is reported once. One exception: a GitHub pre-release later turned into a full release (same tag) is reported again, as a release.
• Legal: see Data sources and terms. No personal data is collected beyond what release notes themselves contain (for example, contributor handles).

Performance

Measured locally (Windows, Node 26) with the platform's memory settings, on 2026-10-11 to 14 (the parsers were also checked on Node 24, the platform's version, with the same timings):

Run	Sources	Duration	Peak memory	Items
Default input (2 GitHub repositories, 1 changelog file)	3	about 3 seconds (1.5 s of work after start-up)	about 150 MB	9
Same, second run with a state key (all unchanged, HTTP 304)	3	about 3 seconds (1.1 s of work)	about 115 MB	0
20 real sources (8 GitHub, 7 changelog files, 3 feeds, 2 release-notes pages), up to 50 versions each, first run	20 (19 with versions)	about 11 seconds	about 235 MB	670
Same 20 sources, next run (16 answered "304 Not Modified", nothing new)	20	about 10 seconds	about 200 MB	0
200 deliberately heavy synthetic sources (3-6 MB changelogs, 1.2 MB pages, 1 MB feeds; no real sites), at the default 512 MB	200	about 2 to 2.7 minutes in 6 of 8 runs; the other 2 stopped early on the memory guard after 66 and 85 sources (outputs written, the rest not charged)	365-414 MB	4,000 when complete
Same 200 synthetic sources at 1 GB	200	about 1 minute 55 seconds	about 515 MB	4,000

Use from an AI agent (MCP)

Apify Actors can be called as tools from MCP-compatible agents and assistants through the Apify MCP server, and from code through the Apify API and SDKs. An agent can ask "what changed in these projects since last week?" with an input like:

{ "sources": ["vercel/next.js", "https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md"], "onlyNewVersions": true, "stateKey": "agent-weekly", "includePrereleases": false }

and read the dataset items (notesMarkdown is ready to quote or summarise) or the DIGEST.md record. See Apify's documentation on the MCP server and the API for setup details.

Integrations

Like every Actor, this one works with Apify's schedules, webhooks and integrations (Slack, email, Google Sheets, Zapier, Make and others) and exports to JSON, CSV, Excel or XML. A typical setup is a saved task with Only report versions that are new since the last run ticked, a daily schedule, and a Slack or email integration that fires when the dataset is not empty (see Running on a schedule).

Support

Open an issue in the Issues tab with the source and the run id; issues are answered in writing. Replies may be drafted with AI assistance and are reviewed before posting.