Uptime
Know before your users do. Tell them before they ask.
Monitoring that only pages you is half a product. The other half is a public place your users already know to check, so that when something breaks your inbox doesn’t become the status page.
API
api.acme.com
99.98%
last 30 days · 118ms
90 days agoHover a dayToday
Checks
Confirmed, not twitchy
An alerting system you learn to ignore is worse than none, so the defaults are built around not crying wolf.
Two consecutive failures before anything fires
A single dropped packet doesn't wake you and doesn't email your subscribers. A monitor flips down only once it has failed twice in a row — and flips back the moment it recovers, with the outage duration attached.Checks on your schedule
A URL, a method, the status code you expect and a timeout. Free runs every five minutes; Pro goes down to one, with ten monitors.Alerts that carry the evidence
A down email doesn’t just say “something is wrong” — it carries the status line, an allow-listed set of response headers, the redirect chain and a couple of kilobytes of the response body. Often you can diagnose it from the notification without opening anything.That evidence is yours alone
A response body can contain stack traces, internal hostnames or credentials, so it is owner-only by construction — it never reaches the public status page, the status feed or the widget.
The status page
A page your users can subscribe to
Public, on your slug, in your colours — with the signature ninety-day bar strip for each monitor.
- Uptime over 24 hours, 7 and 30 days, computed from real checks and cached so the page stays fast under load.
- Ninety days of history at a glance. One thin bar per day, grouped by the viewer’s local day — so a midnight outage lands on the day they actually experienced it.
- Incident history stays visible. Resolved incidents remain, with how long they lasted. Deleting them is what costs trust.
- Subscribers, double opt-in. Anyone can subscribe from the page and gets incident and maintenance notices, with one-click unsubscribe in every email. Twenty-five on Free, unlimited on Pro.
- A status RSS feed too, for people who would rather not hand over an email address at all.
Scheduled maintenance, done honestly
Announce a window ahead of time and Feedfast stops treating it as an outage: no incidents open on the affected monitors, no down-alerts go out, the page reads “under maintenance” instead of red, and your uptime percentage excludes it. Subscribers are emailed when it’s scheduled, when it starts and when it’s done — always with the timezone and UTC offset written out, never a bare “02:00”.
Everywhere else
The same signal, in the places people already are
- An uptime bar strip you can embed in your own footer with one attribute
- Current status in the widget payload, so your app can show it inline
- Email alerts to you in your timezone, to subscribers in the project's
- Ask your coding agent: the MCP server exposes status, latency and open incidents
- Thirty days of check history on Free, ninety on Pro
- Maintenance windows can be scheduled, started, completed or cancelled from the API
If you code with an assistant, the MCP server lets it check uptime right after a deploy and schedule the maintenance window before a migration — without you leaving the editor.
Point a monitor at your site in two minutes
Free for one project with one monitor and a full status page. You'll know about the next outage before the first person emails you about it.