Vendor changelog monitoring: keeping up with what your dependencies change

Every other guide in this library is about writing your changelog. This one is about the other fifty you should be reading. A typical product today sits on a stack of npm or PyPI packages, two or three cloud APIs, a payment provider, an auth provider, a couple of SaaS tools wired in by API, and at least one platform marketplace — each shipping on its own clock, each perfectly capable of changing something you depend on. When an upstream change you didn’t see becomes your incident, the postmortem line is always the same: “the vendor announced this three weeks ago.” Monitoring is cheaper than the postmortem. Here is how to do it without making it someone’s full-time job.

Inventory first: what are you actually depending on?

You can’t monitor a list you haven’t written down. The useful test: if this thing changing behavior would page you, its changelog belongs on the list. Walk the categories — each fails differently:

  • Pinned code dependencies. Everything in your lockfile. Best-served category: update bots exist precisely for this slice.
  • Unpinned and transitive dependencies, base images. The FROM node:22 in your Dockerfile and the dependencies of your dependencies change without ever opening a PR against you.
  • APIs you call. Versioned or dated if you’re lucky — the API changelog guide describes what a good provider gives you. Your job is to consume those signals, not hope.
  • SaaS products you build on. The sneaky category: versionless by design, so there is no number to pin and no upgrade moment. Behavior changes underneath you on their deploy schedule, not yours.
  • Platforms you publish into. App stores, browser extension stores, marketplaces — their policy and API migrations come with deadlines and the platform’s deadline becomes your release whether you like it or not.

Three channels, ranked

1. Bots, for the lockfile slice. Dependabot, Renovate, and friends open the bump PR with the upstream release notes embedded — monitoring solved, mechanically, for exactly the package-manager slice. Your reading job becomes the 30-second merge decision. The trap is coverage inflation: because the bot PRs feel constant, teams assume everything is covered. The bot sees your lockfile. It does not see your payment provider.

2. Feeds, for everything else. RSS solved vendor monitoring twenty-five years ago — for vendors that expose a feed. A “vendors” folder in a feed reader, or a feed-to-chat bridge into a read-only #vendor-changes channel (the pointer-not-archive rule works in reverse: the channel is where you notice, the vendor’s permalink is what you file tickets against). Prefer vendors’ full-content feeds: they let a script grep every entry for the product areas you touch.

3. Page-diff watchers, as a last resort. For the vendor with a changelog page but no feed, a page-change watcher is better than nothing — and strictly worse than everything above it: brittle, noisy on cosmetic edits, silent when the page moves. Needing one is itself information. Tell the vendor; ask for a feed — or skip the asking: our free changelog watcher turns any repo’s Releases, raw CHANGELOG.md, or hosted changelog page into a subscribable RSS feed, refreshed every few hours.

In-band signals beat polling

For APIs, the best monitoring isn’t reading at all — it’s the dependency telling you at call time. RFC 8594 Deprecation and Sunset headers, deprecation warnings from SDKs, warning fields in responses: wire your logging to surface these loudly (a counter that trips an alert, not a debug line nobody greps). A provider that emits them has done half your monitoring for you. Polling the changelog then covers what can’t arrive in-band: the price change, the policy change, the breaking change announced months ahead of any header.

Triage: route by severity, don’t read everything

Reading every entry from fifty vendors is a job nobody will keep doing. Route instead:

  • Breaking and security — interrupt now. When a vendor exposes tags as data, filter on them: a feed or API query for entries tagged breaking or security goes to the on-call channel, not the digest. This is why tags-as-data matters on the publishing side.
  • Everything else — the weekly vendor review. Fifteen minutes, one person, rotating. Skim the folder, open anything touching systems you own, file a ticket per actionable entry. Rotation spreads vendor context across the team instead of concentrating it.
  • Record the no-action decisions too. “Saw the v3 migration notice, we’re unaffected because X” in the ticket is what saves the re-investigation when the sunset date lands. Link the vendor’s permalink — this is what stable entry URLs are for.

Keep a vendor register

The monitoring itself needs to be written down, or it quietly lives in one person’s feed reader and leaves when they do. A VENDORS.md in the infra repo is enough:

## Stripe
Announces at:  https://stripe.com/blog/changelog (RSS yes)
Also in-band:  API version headers, dashboard banners
Blast radius:  checkout, invoicing, webhooks
Watched by:    payments rotation · Last reviewed: 2026-07

One block per vendor: where changes are announced (page + feed URL), what slice of your product it can break, who watches it, when someone last checked that the announcement channel still exists. Audit the register quarterly — vendors move their changelogs, and a feed that went quiet might be a dead URL, not a quiet vendor.

When a vendor has no changelog (or a bad one)

Fallback ladder, best to worst: GitHub Releases (subscribe via the repo’s releases-only watch or its Atom feed) → git tags → reading the commit log — last-resort archaeology that works only for open source and costs the most attention. For closed SaaS with nothing at all, escalate as a customer: renewals and security reviews are leverage, and “how do you communicate breaking changes?” is a standard vendor-questionnaire question — ask it before you’re surprised, in writing. If what they have is a changelog in name only — undated, vague, commit dumps — run it through a changelog linter and attach the graded report: “your changelog scores 34/100 and here’s what that costs us” is a more productive conversation than “we missed your announcement.”

Anti-patterns

  • Relying on vendor email. Marketing gets mailed; breaking changes get a changelog entry and, at best, a buried newsletter paragraph. Email is the vendor’s channel choice, not your monitoring strategy.
  • Watching versions instead of behavior. “No new release” means nothing for versionless SaaS. If a dependency has no versions, monitor its announcement stream, not its version number.
  • The muted firehose. Subscribing to per-commit notifications, drowning, muting the channel, learning nothing. Subscribe at release granularity; if the vendor only offers a firehose, filter it before it reaches humans.
  • Assuming bot coverage is full coverage. Dependabot’s silence says nothing about your auth provider’s deprecation schedule.
  • “We’ll catch it in staging.” Staging exercises today’s behavior. A deprecation announced for six months out is invisible to every test you run this week — it can only be caught by reading.
  • Bus-factor-one monitoring. No register, one diligent person, and the whole practice evaporates with their departure or their vacation.

How this works with Wakelog

Honestly: Wakelog is a publishing tool, not a monitoring dashboard — we won’t watch your vendors for you. The fit is on both sides of the exchange:

  • Be the vendor that’s easy to monitor. Every Wakelog project ships RSS and JSON feeds, stable permalinks, tags as data (?tag=breaking on the public list API), and a machine-readable changelog.md export — the exact surfaces this guide tells your consumers to look for.
  • Run your weekly review into an internal changelog. An unlisted project as the team’s “vendor changes that matter” digest: the reviewer posts the two entries that survived triage, the team subscribes to one feed instead of fifty. The internal changelog guide covers the pattern.
  • Grade before you’re graded. Your own changelog is somebody else’s vendor register entry. The linter shows you what their monitoring scripts and their procurement questionnaire will see.

Start your changelog — free   Next: machine-readable changelogs →

Related guides

Last updated 2026-07-29 · All guides