Loading…
Changelog Observer watches the changelogs, releases, security advisories and status pages of the services your software depends on, and tells you what the vendor actually said. Nothing more.
Free up to 20 dependencies · Sign in with GitHub, Google or an email link · No repository access requested
| Event | Upstream severity | Priority | Impact |
|---|---|---|---|
Elevated error rates on the Payments API 10-17 11:42 · Incident · Stripe · Status page | Critical | Urgent | Unknown |
Prototype pollution in lodash (CVE-2020-8203) 10-17 09:15 · Security advisory · lodash · OSV | Major | High | Unknown |
stripe-node v18.2.0 10-16 18:03 · Release · stripe-node · GitHub releases | Not reported | Normal | Unknown |
Scheduled database maintenance, eu-west-1 10-16 14:30 · Maintenance · Supabase · Status page | Minor | Normal | Unknown |
You never fill in a vendor list by hand. Your agent does the mapping; you keep the decisions.
Say “Set up changelog.observer for this repo.” Your agent reads the manifests, matches each dependency to a known vendor and registers the right feeds through the API or the MCP server.
Vendors that only notify by email get your project’s private inbound address. Confirmation links wait for you under Action needed. Nothing is clicked on your behalf.
Urgent incidents reach you by email and signed webhook within minutes. Routine releases and notices land in a daily digest at a time you choose.
Built for teams that want to know, and hate being interrupted.
Releases, breaking changes, deprecations, advisories, incidents and maintenance, each with its source, severity and the rule that set its priority.
Details →The vendor’s status and yours, side by side. A vendor’s “resolved” never clears an incident for you.
Details →Mail is checked for who really sent it. Unverified senders cannot page you; risky mail is held for review.
Details →A vendor’s “critical” is their word for their outage. Whether your deployment is affected is a separate question, and Changelog Observer never answers it for you.
Create a key with only the scopes you want to grant, connect it to Claude Code or any MCP client, and ask. Every action the agent takes is in the audit log.
project:read, project:write, events:read by default. Rules and destinations need a separate, deliberate grant.Claude Code, one command
claude mcp add --transport http changelog-observer \ https://api.changelog.observer/mcp \ --header "Authorization: Bearer <key>"
Any MCP client, or plain HTTP
curl -H "Authorization: Bearer <key>" \ https://api.changelog.observer/v1/projects
Then say
Set up changelog.observer for this repo.
The limits are published, not discretionary. When a cap is reached, events are still stored and only urgent upstream incidents are delivered until the month rolls over.
No card, no trial clock. Read the pricing page for what each meter means and what happens at a cap.
The same vendor in several projects counts once. Your meters live under Audit & usage in the app.
Sign in, create a scoped key, and let the agent do the mapping.