How to Create a Free Public Status Page for Your API
How to Create a Free Public Status Page for Your API
You've been there. Something feels off. API responses are slow, or maybe they've stopped entirely. You open Twitter. You search the company name. Nothing. You check their docs site. Nothing. You go to their status page and it says "All Systems Operational" in green, last updated three days ago.
Cool. Very helpful.
The "is it down or is it just me?" experience is awful. And if you're building an API that other people depend on, you're going to be on the receiving end of that frustration eventually. A status page won't prevent outages. But it will stop your support inbox from filling up with the same question fifty times while your team is already scrambling to fix things.
What Makes a Good Status Page
Not every status page is created equal. Some are genuinely useful. Others are decoration.
The ones people actually trust have these things:
A component list. Break your service into meaningful pieces. "API," "Dashboard," "Webhooks," "Authentication" -- whatever maps to how your users experience your product. A single green dot for the entire platform tells nobody anything. If your API is fine but your dashboard is down, say that.
Current status per component. Operational, degraded, partial outage, major outage, maintenance. These labels need to update automatically based on real checks, not just when someone remembers to click a button.
Uptime history. The little bar chart showing the last 90 days. Users glance at this to decide whether your service is generally reliable or if it's held together with tape. A 99.9% uptime number is reassuring. A page full of red bars from last month is not.
An incident timeline. When something breaks, people want to know what happened, when you found out, and what you're doing about it. Timestamps matter. "We're investigating" at 2:14 PM, "Root cause identified" at 2:31 PM, "Fix deployed" at 2:58 PM. That kind of transparency builds trust, even when things are broken.
Self-Hosted Options
If you want to run your own status page, there are a few open-source projects worth considering.
Cachet
Cachet is the one everyone mentions first. It's PHP/Laravel, looks decent out of the box, and has components, incidents, and metrics.
The problem: development has mostly stalled. The GitHub repo shows sporadic activity but no real release cadence. Issues pile up. If you're comfortable maintaining a PHP app and patching things yourself, it works. If you want something actively maintained, look elsewhere.
Upptime
Upptime takes a different approach. It runs entirely on GitHub Actions and GitHub Pages. No server needed. You configure your monitors in a YAML file, GitHub Actions runs the checks on a cron schedule, and the results get committed to your repo. The status page is generated as a static site.
# .upptimerc.yml
sites:
- name: API
url: https://api.yourapp.com/health
- name: Dashboard
url: https://app.yourapp.com
- name: Webhooks
url: https://api.yourapp.com/webhooks/health
method: POST
It's free (GitHub Actions minutes for public repos are free). The downside is check frequency -- GitHub Actions cron jobs run at most every 5 minutes, and sometimes they're delayed. If you need faster detection, this won't cut it. And the incident management is basically creating GitHub issues, which feels clunky.
Gatus
Gatus is newer and written in Go. Single binary, minimal config, comes with a built-in status page.
endpoints:
- name: API
url: "https://api.yourapp.com/health"
interval: 30s
conditions:
- "[STATUS] == 200"
- "[RESPONSE_TIME] < 2000"
- name: Webhooks
url: "https://api.yourapp.com/webhooks/health"
interval: 60s
conditions:
- "[STATUS] == 200"
It's lightweight, actively maintained, and you can host it on a $5 VPS. The status page UI is functional but basic. No incident management built in -- it just shows pass/fail for your endpoints. You'd need to handle incident communication separately.
SaaS Options
Don't want to host anything? There are plenty of managed options.
Statuspage.io by Atlassian is the market leader. It starts at $29/month for the Hobby plan (1 page, 25 components). It looks professional, supports incident updates, has subscriber notifications, and integrates with tools like PagerDuty and Opsgenie. The catch: it's just a status page. It doesn't monitor anything. You need a separate monitoring tool to feed data into it. So you're paying $29/month for the page, plus whatever your monitoring costs.
Instatus starts at $20/month and covers similar ground. Cleaner UI than Statuspage in some people's opinion. Also doesn't include monitoring -- you'd connect it to UptimeRobot or Better Stack or whatever you're already using.
Better Stack bundles monitoring and status pages together. Their free tier includes basic uptime monitoring, and paid plans start at $24/month. This is closer to what most small teams actually need: checks that detect problems and a page that reflects those checks automatically.
How ThunderHooks Status Pages Work
ThunderHooks takes the bundled approach. Status pages are tied directly to the monitoring you're already doing.
Here's the idea: you set up monitors (HTTP health checks), heartbeat monitors (for services that ping you), and API tests (multi-step request sequences). Each of those produces a stream of pass/fail results. A status page component links to one of these checks. When the check passes, the component shows green. When it fails, it goes red. No manual button-clicking.
Components support four status states:
- Operational -- checks are passing
- Degraded performance -- checks pass but response times are elevated
- Partial outage -- some checks failing
- Major outage -- everything is failing
You can also set an override status manually -- useful for planned maintenance windows where you don't want automated checks to flip things around.
Setting It Up
- Create your monitors (if you haven't already). Point them at your API endpoints, dashboard, webhook handler, whatever your users care about.
- Create a status page. Give it a name, pick your brand color, upload your logo.
- Add components. Each component gets a name and a linked monitor, heartbeat, or API test.
- Toggle it public.
Your page lives at a URL like status.thunderhooks.com/your-company. Custom domains are on the roadmap.
Customization
You can set a brand color, add your logo, and inject custom CSS if the defaults don't match your brand. Components can be reordered by display priority. Group related services together -- put your core API endpoints first, background jobs and minor features below.
Incident Management
Automated status is great for the 90% of situations where checks tell the full story. But sometimes you need to communicate more than "up" or "down."
Maybe your API is technically responding but returning stale data because a cache layer is broken. Monitors show 200 OK. Users see wrong numbers. The status page says operational. That's worse than showing nothing at all.
This is where manual incidents come in. ThunderHooks supports creating incidents with:
- A title describing the issue ("Stale data returned from /v2/reports endpoint")
- Impact level -- none, minor, major, critical
- Status updates as things progress -- investigating, identified, monitoring, resolved
- Timestamped update messages so users can follow along
The workflow during an actual incident looks like this:
- Something breaks. Automated checks catch it (or a user reports it).
- Create an incident. Set impact to major. First update: "Investigating reports of incorrect data from the reports API."
- Dig into the problem. Post an update: "Identified a stale Redis cache causing the reports API to serve outdated data. Working on a fix."
- Deploy the fix. Update: "Fix deployed. Cache has been flushed. Monitoring to confirm data is fresh."
- Resolve the incident after confirming things are stable.
Each update shows on the public status page with a timestamp. Users see that you know about the problem and are actively working on it. That's all most people need to stop panicking.
Pricing Comparison
Here's where things get interesting for small teams trying to decide.
Statuspage.io: $29/month for the status page alone. No monitoring included. You'll need UptimeRobot ($7/month for pro) or Better Stack ($24/month) or something similar to actually detect downtime. Total: $36-53/month for status page + monitoring.
Instatus + monitoring: $20/month for Instatus plus your monitoring tool of choice. Similar total.
Better Stack: Starts at $24/month and includes both, but the status page features on lower tiers are limited.
ThunderHooks Pro: $19/month. Includes 1 status page, 3 monitors (5-minute intervals), 20 heartbeat monitors, 5 API tests, and 5,000 credits. The monitoring that feeds your status page is the same monitoring you're already using for webhook endpoint health checks and alerting. One tool, one bill.
If you're already using ThunderHooks for webhook testing or relay, the status page is just another feature on your plan. You don't need a second vendor.
Status Page Launch Checklist
Before you point users at your status page:
- Components match what users care about (not your internal service names)
- Each component is linked to a working monitor or heartbeat
- Monitors are running at an interval that makes sense (every 5 minutes minimum)
- You've verified the page loads correctly when logged out
- Someone on the team knows how to create an incident and post updates
- Your brand colors and logo are set so it doesn't look like a default template
- You've linked to the status page from your docs, footer, or help center
- Alert channels are configured so you know about outages before your users do
- You've tested the incident workflow end-to-end -- create, update, resolve
That last point matters more than people think. You don't want to be figuring out the incident UI for the first time during an actual outage at 3 AM. Do a dry run. Practice posting an update. Delete the test incident when you're done.