Track Outage Reports and Status Pages for a Website

When a website goes down, two things happen at once. Your monitoring should notice within minutes, and your users start posting about it, usually on X and usually before they email anyone. A good setup covers both: an automated check that tells you the site is down, and a search that tells you what people are seeing and saying.

This guide walks through a free version of each. No paid service is required, and we don't recommend a specific vendor.

Part 1: free uptime monitoring

An uptime monitor is a service outside your infrastructure that requests a URL on a schedule and alerts you when the answer is wrong. "Outside" is the important word. A check that runs on the same server as your site can't tell you the server is down.

What to check

Start with three checks:

1. The home page, expecting an HTTP 200 response.
2. One page that touches the database, such as a login page or a search results page. A static home page can load from cache while everything behind it is broken.
3. A keyword on the page. Many monitors can confirm that a specific word appears in the response. That catches the case where the server returns 200 with an error message or a blank template.

If you run an API, add a check against a lightweight health endpoint. If you depend on a payment provider or email service, watch their public status pages too.

Where to run it

There are three common free routes.

Hosted monitoring services usually have a free tier with a handful of monitors and checks every few minutes. Limits change, so compare the current check interval, the number of monitors, and which alert channels (email, mobile push, chat webhooks) the free plan includes.

Self-hosted open-source monitors such as Uptime Kuma run on a small server or a spare machine. You get unlimited checks and full control, as long as you host it somewhere other than the site it watches.

A scheduled script is the minimum version: a cron job on another machine that runs curl against your URL and sends an email when the status isn't 200. It's crude but better than nothing.

Tune the alerts

The most common failure of uptime monitoring isn't missing an outage. It's alerting so often that people stop reading the alerts. Require two consecutive failures before alerting, check from more than one region if the service allows it, and send alerts to a channel someone actually watches at night. Write down who responds when an alert fires.

Part 2: a status page

A status page is a simple public page that says whether your service is working, and if not, what you know so far. It saves your support team from answering the same question two hundred times.

Keep it independent of your main hosting: a static page on a different provider, or the status page feature many uptime services include. Put a link to it in your site footer, help center, and X profile.

During an incident, update it in plain language: what's affected, when it started, what you're doing, and when you'll update next. "Checkout is failing for some customers since 14:10 UTC. We're investigating. Next update by 14:45" is better than "We are experiencing degraded performance."

Part 3: where people report outages on X

Users report outages in a few predictable ways:

• Tagging your account: "@acme is your site down?"
• Replying to your latest post, even if it's about something else.
• Posting without a tag: "is acme down for anyone else"
• Posting an error code or a screenshot of the error page.
• Asking in replies to larger accounts in your niche.

Outage aggregator sites also collect user reports and spikes in social posts, so if one of them lists your service, people will find it through search and repost the link.

A search that catches them

Build a query that combines the ways people refer to your site with the words they use when it breaks:

(acme OR acme.com OR @acme) (down OR outage OR "not working" OR "not loading" OR "can't log in" OR 502 OR 503 OR 504) -from:acme

Open it on the Latest tab and save it. The query builder has an "Outage reports for a site" example that sets this up; replace the example domain with yours.

A few refinements help. Add -filter:links if news articles and bots sharing links flood the results; first-hand reports rarely include a link. If you serve one region, add lang:en or your main language. And during a real incident, add since: with today's date to hide last month's complaints.

Watch the platforms you depend on

Your site can break because a provider broke. Find the official status accounts of your hosting provider, CDN, payment processor and email service, put them in a private list, and turn on post notifications for the two or three that would take you down. When your monitor fires, glance at that list before you start debugging your own code.

During the incident

Use X as a broadcast channel, not just a listening post. Post a short acknowledgment from your main account as soon as you've confirmed the problem, link the status page, and pin the post. Update the same thread as you learn more, so anyone who finds the first post sees the whole story.

Reply to the people who reported it, briefly and with the status link. Don't copy-paste the same reply to dozens of users in a burst; that looks like spam to both people and X's systems. A pinned post and a status page do most of the work.

After the fix, post a short all-clear and update the status page. If the outage was long or affected payments, a short write-up a day or two later earns a lot of goodwill.

A minimal setup in one list

• Two or three external uptime checks, alerting after two failures.
• A status page hosted somewhere else, linked from your site and X profile.
• A saved X search for outage words plus your name and domain.
• A private list of your providers' status accounts.
• A named person who responds to alerts, and a template for the first post.

The guides here are general information. MoniTwitter is independent, has no affiliate relationships with any monitoring service, and is not affiliated with X Corp.

Questions