Cachet Update — July 2026

It's been a busy couple of weeks for Cachet, and this update has a little bit of everything: a brand new way to manage your status page, completed subscriber support, a security fix you should update for, and a long list of bug fixes.

Let's get into it.

Cachet now speaks MCP

The headline feature this month: Cachet ships with a built-in MCP server. If you're using AI agents as part of your incident response — Claude Code, Claude Desktop, Cursor, or anything else that speaks the Model Context Protocol — they can now operate your status page directly.

Everything you can do from the dashboard is exposed as an MCP tool: components and component groups, incidents and their updates, incident templates, maintenance schedules, metrics, and subscribers. An agent can pick up a page, open an incident from a template, flip the affected components, post updates as the situation develops, and mark everything fixed when it's over.

The MCP server is disabled by default. Turn it on from the dashboard settings and it becomes available at the /mcp path of your installation, using the streamable HTTP transport:

claude mcp add --transport http cachet https://status.example.com/mcp \
  --header "Authorization: Bearer YOUR_KEY_HERE"

Authentication uses the same API keys as the Cachet API, and the permissions on the key decide which tools an agent gets. In addition, write tools aren't even advertised to a session unless its token holds the matching permission, so an agent connected with a read-only key sees a read-only server. By default all connections require a key, though you can make the read-only tools public — in which case they see exactly what a status page visitor sees.

The MCP server documentation covers setup, authentication, and the full list of tools and their required permissions.

Subscribers are complete

One of the most-loved parts of Cachet 2.x is now complete in 3.x: people can subscribe to your status page and receive updates by email.

Visitors subscribe from the status page, confirm their address via a verification email, and from then on Cachet keeps them informed:

• When an incident is created, and each time it receives an update.
• When maintenance is scheduled, and when a schedule is updated, rescheduled, or completed.

You stay in control of the noise — creating an incident lets you choose whether subscribers are notified, and every email carries an unsubscribe link so people can opt out at any time.

Subscribers can be managed from the dashboard, through the API, and — as of this update — over MCP.

Security: API visibility scoping

We published a security advisory, GHSA-6ghm-wf22-pvx5: the public API endpoints could reveal resources that were hidden on the status page — such as components in hidden groups — to unauthenticated callers. The API now scopes results to what the caller is allowed to see, matching the status page. If you're running Cachet 3.x, please update.

While we were in that area, we hardened a few more things:

• Reading subscribers via the API now requires an API key with the subscribers permission. Subscriber records contain email addresses, and they should never have been readable without one.
• User-authored Markdown — incident messages, the about section, and so on — is now sanitized when rendered on the status page. Raw HTML is stripped and unsafe links are removed.
• You can now disable the API entirely, or require authentication for all requests, directly from the dashboard settings. Not everyone wants a public API, even a read-only one.

Two-factor authentication

Dashboard users can now secure their accounts with app-based two-factor authentication. Enable it from your profile, scan the QR code with your authenticator app, and store the recovery codes somewhere safe.

Metadata

Components, component groups, incidents, schedules, and subscribers now support arbitrary metadata via the API. If you're integrating Cachet with your own tooling, you can attach whatever context you need — internal ticket references, team ownership, region — and read it back later. Existing component metadata is migrated automatically.

API improvements

• API requests that previously blew up with a 500 now return proper validation errors, and we fixed a number of mismatches between the API documentation and what the API actually accepts.
• Cachet's API no longer inherits the host application's rate limiter. It has its own, configurable via CACHET_API_RATE_LIMIT.

Performance

We spent some time profiling Cachet and shipped improvements across the status page, API, and dashboard — fewer queries and less duplicated work per request. Larger status pages should feel noticeably snappier.

The status page favicon is also dynamic now: it reflects your current system status, so a glance at the browser tab tells you whether everything is operational.

Bug fixes

A good number of bugs were squashed this month:

• The IncidentUpdated event was dispatched twice for every incident update, which meant webhooks fired twice too.
• Partially updating a component through the API no longer re-enables a disabled component.
• The incident overview on the status page counted an incident once per update, inflating the numbers.
• Incident messages containing certain characters could break the RSS feed.
• Metric thresholds could not be updated after creation.
• The dashboard components widget now shows non-public component groups, so hidden components are no longer invisible to the people managing them.
• The dashboard rejected logins in production environments due to a missing Filament panel access check (#390).
• The component_checks migration used the wrong column type for component_id (#388).

Thank you

As always, thank you to everyone who reported issues, contributed fixes, and sponsors Cachet — this work happens because of you.

If you want to get involved, come and say hi on GitHub or Discord.

Until next time,

James