What does the tool actually check?
A status page tool should prove what each check proves, so ask that before pricing and before design. How many locations does the tool run checks from, and are they real independent regions or one location described generously? Does the public page show per-region or per-component results, or does everything collapse into a single operational/degraded/down badge before it reaches the page?
A tool that checks from four places internally but only ever shows you one number has thrown away the most useful part of what it measured. The full reasoning is in the uptime monitoring guide.
Ask, too, what counts as “down.” A tool that flips state on a single failed probe will generate false alarms during ordinary network noise. A better tool requires a failure to persist for a few minutes before changing state. It also requires a confirmed success to recover. The result is a page you can trust instead of one you learn to tune out. Google's SRE book describes the cost of noisy alerts in Monitoring Distributed Systems.
How incidents get created and communicated
Ask specifically:
- Does an incident draft automatically from a confirmed monitor transition, or does a human have to notice and write it by hand every time? Manual-only incident creation means your status page's honesty depends on someone remembering to update it while they're also busy fixing the actual problem.
- Does the incident lifecycle match how real incidents unfold (investigating, identified, monitoring, resolved), or is it a single freeform text box with no structure?
- Do resolved incidents stay visible in a history, or do they disappear from the page once closed? A page that only shows active incidents can accidentally make your reliability look better than it's been.
- Does it support scheduled maintenance windows that suppress alerts without hiding the window itself?
The stage-by-stage cadence, and what to write at each stage, is a separate question. The tool question here is narrower: does the product's structure support that workflow, or fight it?
Do subscriber notifications come with the plan?
Subscriber notifications are included only if the tier you would actually pay for includes them. A status page with no way for customers to subscribe only helps people who think to check it. During a real outage, those people are a small fraction of the people affected.
Confirm subscriber email notifications are not gated behind an enterprise plan. Confirm there is a real unsubscribe path. A broken or fake unsubscribe link is a trust problem and, depending on your audience, a compliance one. RFC 8058 defines the one-click unsubscribe mechanism that mailbox providers look for.
Alerting into your own tools
Separate from customer-facing subscriber notifications, check what your own team gets paged through: email, Slack, and outbound webhooks are the common baseline.
Suppose you need a specific integration, such as PagerDuty, Teams, or a custom internal system. A generic webhook with a verifiable signature is usually more durable than waiting for a vendor to build a bespoke integration for your stack. GitHub's documentation on validating webhook deliveries shows the HMAC signature pattern to look for.
On-call and team access, if you need them
Some teams need on-call scheduling and escalation policies built into the same tool; others just need the status page and a Slack channel. Be honest with yourself about which one you are before you pay for the first. Similarly, check whether the tool supports multiple team members with separate logins and permissions, or is single-account by design, if more than one person on your team needs to post updates.
Pricing shape, not just the number
Two tools at the same headline price can behave very differently once you use them. Per-subscriber or per-check-response metering means your bill grows with your success, exactly when you can least afford a surprise invoice. A flat rate per tier is more predictable and easier to budget against, though it usually comes with a monitor-count ceiling instead.
Check the free tier's real limits (monitor count, check interval, notification channels) against what you need on day one, not what you'll grow into eventually. A free tier that is unusably small isn't really free. It is a forced early upgrade.
Custom domain and branding
A status page under a vendor's own domain (yourcompany.statuspagevendor.com) works, but a status page at status.yourcompany.com reads as part of your product, not a third-party add-on. Check whether a custom domain is included and what tier it requires. Check whether TLS is issued and renewed automatically or is something you have to manage yourself. Automatic issuance usually follows the Let's Encrypt model.
What should you test before committing?
Most of these tools have a real free tier or a trial. Use it to answer the questions above with the actual product instead of its marketing page. Add a monitor, then watch a check fail by pointing it at a URL that returns an error or a host that times out. See how fast and how clear the resulting alert and status-page update are.
Read the incident templates the tool auto-generates, if it has any. You will be shipping that wording to your own customers whether you edit it or not.
Where RealUptime Status fits, honestly
RealUptime Status checks every monitor from several independent regions (four regions on Free, eight on Pro, all ten on Business) and publishes each region's state separately, with a two-consecutive-failure threshold before anything is treated as down. Incidents auto-draft from real transitions and stay visible in a resolved history. Subscriber emails and Slack and webhook alerts to your team are included on every tier.
Team logins are included too (3 people on Free, 10 on Pro). The tier limits are worth knowing before you sign up, not after: on-call rotations with escalation are part of the paid plans. Named, sourced feature-by-feature comparisons against specific tools are in the comparison pages.
Next