Dependency Release Monitor - npm, PyPI & GitHub

Watches the packages your code depends on and tells you when one ships a new version - across npm, PyPI and GitHub releases in a single schema. Every row says how big the jump is (major, minor, patch), whether it looks breaking, and what the release notes actually said. It remembers what it has already reported, so a run is quiet until something genuinely ships.

Live health record: lowlanddata.com/status/dependency-release-monitor - 30-day success rate and daily canary results, failures included. Full input/output reference: tool page.

It reads the registries' own public endpoints - the npm registry document, the PyPI JSON API, and the GitHub releases feed. No API key, no GitHub token, no rate-limit babysitting, no scraping around a defence. Maintainer names and addresses sit in two of those three sources; none of them are read, so a row carries versions and dates and nothing about a person.

Quick start (30 seconds, no keys needed)

1. Hit Start with the prefilled packages: ["npm:zod", "pypi:requests", "github:apify/crawlee"]. It finishes in seconds and returns the current version of each - that is the baseline.
2. Replace the list with your own. Write npm:name, pypi:name or github:owner/repo; a bare express means npm and a bare owner/repo means GitHub.
3. Add a daily schedule (Actor page -> Schedule). From then on the runs are silent until one of your dependencies publishes.

Point a webhook at it and a new release lands in Slack, a Linear ticket, or your own endpoint before you read it on a changelog site.

Who uses this

• Platform and infra teams watch the 30 libraries that hold production up, filter isBreaking: true, and open a ticket only for those.
• Agencies maintaining many client stacks run one profile per client with its own stateStoreName, so each digest carries that client's dependencies only.
• Security and compliance people track when an upstream stops shipping, using releasedAt to spot a package that has gone quiet for a year.
• AI coding agents call it over MCP before proposing an upgrade: "what changed in these five packages this month, and does any of it break me?"
• Anyone who has ever been surprised by a major version in a Monday morning CI failure.

What you get

One JSON item per release. The first run pushes each package's current version so you can see what is being watched; after that, only versions published since the last run.

A quiet patch release:

{
  "package": "zod",
  "ecosystem": "npm",
  "version": "4.5.4",
  "previousVersion": "4.5.3",
  "releasedAt": "2026-08-29T17:55:42.775Z",
  "semverBump": "patch",
  "isBreaking": false,
  "isPrerelease": false,
  "url": "https://www.npmjs.com/package/zod/v/4.5.4",
  "isBaseline": false
}

The row you actually bought the tool for - a major bump, with the notes that say why:

{
  "package": "acme/widget",
  "ecosystem": "github",
  "version": "v2.0.0",
  "previousVersion": "v1.9.3",
  "releasedAt": "2026-09-01T08:12:00.000Z",
  "semverBump": "major",
  "isBreaking": true,
  "isPrerelease": false,
  "url": "https://github.com/acme/widget/releases/tag/v2.0.0",
  "highlights": ["drops Node 18", "renames the client export"],
  "notes": "Breaking change\n- drops Node 18\n- renames the client export",
  "isBaseline": false
}

And the one everybody else's README hides - a package that could not be read. The run does not die for it; the failure is recorded, the other packages still report, and the run summary says how many targets failed:

WARN  github:acme/private-repo failed: HTTP 404
INFO  [Status message]: 3 new releases across 12 watched packages.

Field honesty notes:

• previousVersion is the version published immediately before this one, by version order - not by date. A back-ported 1.4.9 released after 2.0.0 is still recorded as following 1.4.8.
• semverBump is unknown when a tag is not a version at all (nightly, 2026-09-01), because guessing would be worse than saying so.
• isBreaking is true on a major bump, on a 0.x minor bump (where projects actually put their breaks), or when the release notes announce one. It is a strong hint, not a promise - read the notes.
• notes and highlights exist only where the source publishes them, which in practice means GitHub releases. npm and PyPI publish no release text at all, and inventing one is not on the table.
• releasedAt for GitHub is the release's own timestamp, which can differ from the tag's commit date.

How change detection works

Every monitor on this store is vague about this, so here it is in full:

• Where the memory lives. A named key-value store on your account (stateStoreName, default dependency-release-monitor-state). One entry per profile - the hash of your package list. Nothing about your monitor is stored anywhere else; there is no server on my side holding your list.
• What the first run does. It records every version currently published as already-seen, and pushes one row per package (its current version) so the run is not empty. That is the baseline. Set emitBaseline: false if you want the first run silent.
• What later runs do. They fetch the current version list, subtract everything already seen, and report the difference. Nothing new means an empty run.
• Does a quiet check still cost? Only the actor start. There is no per-check charge: a run that finds nothing costs a fraction of a cent, which is what makes an hourly schedule sane.
• Changing the list. Adding or removing a package changes the profile, so the new profile takes one baseline run before it alerts. Use a separate stateStoreName per client or per project to keep them independent.
• Starting over. resetState: true forgets everything and re-baselines.

What a release monitor costs

Pay per outcome: checking is free, you pay when there is news.

Event	Price	When it is charged
New release alert	$0.0199 (from $0.0185 on paid plans)	A version published since the last run
Baseline result	$0.00199	Once per package on your first run only
Actor start	$0.005	Per run, whatever it finds

Live prices are always the ones on this page's Pricing tab. A worked example: 25 packages watched hourly. The first run costs $0.005 + 25 x $0.00199 = about 5.5 cents. Every quiet run after that costs half a cent, and a busy month with 40 real releases costs roughly $4.40 including all 720 checks. New Apify accounts come with free monthly platform credits, so the first runs cost nothing out of pocket.

Why an alert costs more than a row

Because the value is in what is not sent. Anything can print a list of versions; the work here is remembering across runs so that a row appearing in your inbox means something changed. You pay for the signal, not for the polling.

Input reference

Field	Type	Default	What it does
packages	string[]	three sample packages	What to watch: npm:name, pypi:name, github:owner/repo, or a bare name
onlyBreaking	boolean	false	Alert only on releases flagged breaking
includePrereleases	boolean	false	Include alpha, beta and rc versions
includeNotes	boolean	true	Include the full release-notes text where the source has one
maxPerPackage	integer	20	Cap per package per run, so one nightly-build dependency cannot flood a run
emitBaseline	boolean	true	Push current versions on the first run
resetState	boolean	false	Forget the memory and re-baseline
stateStoreName	string	dependency-release-monitor-state	Which named store holds this monitor's memory
maxItems	integer	500	Stop after this many rows

The package list is also accepted under dependencies, deps, repos or libraries, and a single comma-separated string works as well as a list - so an AI agent's first guess at the input tends to run.

Scheduling and API use

Daily is right for most stacks; hourly is affordable because quiet runs are nearly free. Start a run over the API:

curl -X POST "https://api.apify.com/v2/acts/lowlanddata~dependency-release-monitor/runs?token=YOUR_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"packages":["npm:zod","npm:express","pypi:django","github:apify/crawlee"],"onlyBreaking":true}'

Then fetch only the breaking ones from the dataset:

$curl "https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&filter=isBreaking"

Use it with AI agents (MCP)

Every tool here doubles as an MCP endpoint, so Claude, Cursor or your own agent can run it directly: dependency-release-monitor/api/mcp. A prompt that works as-is:

Using the dependency release monitor, check npm:zod, npm:hono and pypi:fastapi
for anything published in the last month, and tell me which upgrades look breaking.

Is this legal, and what about personal data

Yes - and it is boring on purpose. The actor reads three public endpoints that exist to be read by package managers, at a handful of requests per run. It authenticates to nothing and needs no token.

The npm registry document carries maintainer names and email addresses, PyPI carries an author and author-email, and the GitHub feed carries the publishing account. None of them are read. The parser takes versions, dates, tags and notes; a test in the build feeds each source a record stuffed with fake names and addresses and fails if any of it survives to the output. So the rows are safe to store, forward and archive without a compliance conversation.

Sources and honest coverage notes

• npm - registry.npmjs.org, the same document npm install reads. Complete version history with publication timestamps.
• PyPI - pypi.org/pypi/<name>/json. Yanked releases are skipped, since a yanked version is one you are being told not to install.
• GitHub - the repository's public releases feed. Repositories that tag without creating releases publish nothing to that feed, so a project using bare tags will look quiet. Private repositories are not accessible.
• Ecosystems not covered yet: crates.io, Packagist, Maven, Go modules, RubyGems. If you want one, ask - adding a registry is a small job.

FAQ

Does it open pull requests like Dependabot? No, and deliberately. This is the notification half: it tells you what shipped, in one feed across three ecosystems, wherever you already read things. Nothing is written to your repository.

Will an hourly schedule bankrupt me? No. A run that finds nothing charges only the actor start, so hourly costs about 12 cents a month plus whatever real releases happen.

Can I watch a package I do not depend on? Yes - competitors' SDKs, a framework you are evaluating, anything with a public registry entry.

Why is my GitHub repository silent? It probably tags without publishing releases. Watch the package on npm or PyPI instead if it publishes there.

Can I get only major versions? onlyBreaking: true gives majors, 0.x minors and anything whose notes announce a break.

Where does my package list live? In a key-value store on your own Apify account. I never see it.

More tools from Lowland Data

Same house rules everywhere: clean schemas, public sources, no personal data in the output.

Tool	What it does
SSL & Domain Expiry Monitor	Certificate and domain-registration countdowns for a list of hosts
US Federal Grants Monitor	New federal funding opportunities matching your profile
Company Jobs Scraper	Every open role from any Greenhouse or Lever board

Full catalogue: lowlanddata.com/catalogue.

Support

Something wrong, a registry you need, or a release the monitor missed? Open an issue on the Issues tab with the run ID, or write to contact@lowlanddata.com. Reports get read the same day.