A Statuspage.io alternative that knows when you're down

Atlassian Statuspage is a place to publish incidents. It doesn't detect them. Something else has to notice your API is failing and either tell Statuspage or wake up a person who then writes the incident by hand. Stector puts both halves in one product: HTTP checks run from up to three regions. When a monitor goes down, an incident opens, and the component on your public status page changes state without anyone logging in. It has real gaps, the biggest being no custom domain for status pages yet. If status.yourcompany.com is a hard requirement today, skip to "Who should stay with Statuspage."

#What Statuspage is genuinely good at

Statuspage has the deepest packaging of any status-page product compared here, and it's built for organizations bigger than the ones Stector targets. Plans, limits and channels below are as its pricing page and pricing FAQ showed them on 2026-10-14:

• Audience-specific pages, which Atlassian's pricing FAQ describes as having their own separate pricing model, chosen under Your page > Page type.
• Private pages, on a pricing ladder separate from public pages: Starter $79/mo, Growth $249/mo, Corporate $599/mo and Enterprise $1,499/mo. Their limits count authenticated subscribers, and Atlassian pitches them for telling employees about internal tools.
• Large subscriber and team ceilings. Public plans go up to 25,000 subscribers and 50 team members.
• More notification channels as you move up. The pricing table's Notifications row lists email, Slack and Microsoft Teams on Hobby, and adds SMS and webhook from Startup.
• Custom domains on all four paid tiers, starting with Hobby at $29/mo.
• Native fit with the rest of Atlassian, plus a brand your security and procurement teams have probably already approved.

If you need those things, Statuspage earns its price.

#Where small teams start to resent it

Two patterns come up for a 5-to-50 person team.

You're paying for two tools and wiring them together. Statuspage has no built-in monitoring at any tier. You run an uptime tool, then connect it through an integration or a webhook, or you accept that the page is only as current as the person on call. At 3am that person is busy fixing the outage, so the page lags.

The plan axis is subscriber count. Statuspage's public tiers are priced by how many subscribers you have. On 2026-10-14 the pricing table listed four paid tiers, from $29/mo:

Every email address, SMS number, Slack channel and webhook counts as one subscriber. A B2B product with a few hundred customer accounts can outgrow Hobby on a quiet afternoon. That's not a criticism of the model, since subscribers cost money to notify, but it means your status-page bill tracks your customer count rather than what you monitor.

#How Stector handles the same job

Detection is built in. You create HTTP monitors (GET, POST, PUT, DELETE or HEAD, with an exact expected status code and optional bearer, basic or custom-header auth). On Pro and Business, each monitor can check from US East, EU West and Asia. You then link status-page components to monitors. Unless you set a component's status by hand, it's computed from them: all linked monitors up is Operational, some up and some down is Partial Outage, all down is Major Outage.

Incidents follow the checks. When a monitor goes down, Stector opens an incident in Investigating, and it shows on your page if that monitor is linked to a component. When the monitor recovers, the incident resolves. If it recovers while a maintenance window covers it, the incident stays open until you close it. You can post Identified and Monitoring updates in between, from the dashboard or the API.

Here is the rule. Once a monitor is running from more than one region, a failure must be seen twice in a row from a region, and two regions must agree, before it pages you. That's how Stector is set up to decide. For a monitor on all three regions at a 1-minute interval:

For the same three-region monitor, recovery is quicker: it's back up once two regions each report one successful check, even if the third is still failing. Recovery needs one good check per region, not two in a row. A two-region monitor is set up to need both regions to report a successful check, apart from a new or just-resumed monitor's first check (below). A one-region monitor needs one. That includes every Free monitor and any paid monitor set to one region. The limits and exceptions, stated plainly:

• On a monitor checking from two or three regions, Stector is set up not to page you for an outage visible from only one of them. If one region sees failures and the others see your endpoint up, no incident opens. That's the design, and sometimes it's the wrong call for you. The exception is a new or just-resumed monitor's first check (next item).
• A new or just-resumed monitor is the exception to the rule. On a new or just-resumed monitor, even if it's set to three regions, the first check decides, in either direction, from one region. So one failed check can mark it down and page you.
• A monitor checking from one region (every Free monitor, or a paid monitor you set to one region) needs two failed checks in a row from that region.
• There are three regions: US East (Ashburn), EU West (London) and Asia (Singapore). Nothing checks from Oceania or South America.

Subscribers and maintenance are included. Visitors subscribe by email on a status page and confirm through a verification email whose link is valid for 24 hours. Each page has its own subscribers. Confirmed subscribers are emailed about incidents shown on their page: when one opens, whether Stector opened it because a monitor went down or someone created it in the dashboard, the REST API or the MCP server; when someone posts an update to the page; and when it's resolved, except when a plan-limit pause closes it. An update sent through the API or MCP with postedToStatusPage set to false stays off the page and emails no one. A manual incident is shown only on the page it is posted to; an automated one appears on every public page whose components link its monitor. While a maintenance window covers a monitor, Stector holds back that monitor's down and recovery alerts and opens no automatic incident. If a monitor the window lists goes down during the window and is still down when the window ends, the down alert is sent and an incident opens on the next check after the window ends, with its start time set to when the monitor went down. Windows can also email subscribers when they start, end or are cancelled. A window belongs to the status page you schedule it from: only that page shows its banner, and only that page's subscribers are emailed about it. Holding back alerts isn't limited to the window's own page. While the window is in progress, a monitor you list under Affected monitors sends no down or recovery alerts to any of your alert channels and opens no automated incident, whichever page the window belongs to. So none of your status pages shows a new incident for it, including pages that link that monitor and have no window of their own. On those pages, components linked to the monitor keep showing its real status, with no maintenance banner, and their subscribers get no email about it. An incident that opened before the window began is not closed automatically on any page if the monitor recovers during the window. You can resolve it manually.

You can drive it from a script. On Pro and Business you can create a personal access token for the REST API. Posting an update to an open incident:

curl -X POST https://api.stector.app/api/v1/incidents/$INCIDENT_ID/updates \
  -H "Authorization: Bearer $STECTOR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Root cause identified: expired DB credentials. Rotating now.",
    "status": "identified"
  }'

That update appears on each public page that shows the incident, and is emailed to that page's subscribers. The same token works with Stector's 17-tool MCP server if you'd rather do this from an AI client.

The status page runs apart from the app. Stector's status pages are served by Cloudflare Workers from edge cache and never share a database connection with the main app's request path. It still reads the same database, through Supabase's API rather than the app's connection pool. If the Stector dashboard is having a bad day, your status page shouldn't be.

You can see a live one: Stector's own status page is at stector.stector.app.

#Side by side

Stector's plans:

• Free: $0. 10 monitors, 3 SSL monitors, 3-minute minimum interval, 1 region, 1 member, email alerts, status page on yourname.stector.app with Stector branding.
• Pro: $19/mo, or $15/mo billed $180 annually. 50 monitors, 25 SSL monitors, 1-minute interval, 3 regions, 5 members, email and Slack alerts, API and MCP access, email support.
• Business: $49/mo, or $39/mo billed $468 annually. Everything in Pro, plus unlimited monitors, unlimited members and priority email support.

Free includes 1 public status page, Pro 3 and Business 10, each at its own yourname.stector.app address with Stector branding. Business is the plan the pricing page marks "For agencies": that's a page per client for up to ten clients, with the limits that come with it. Every page shows "Powered by Stector", none has a custom domain or white-label, and roles are team-wide, so every member sees every page; there are no per-page permissions. An agency with more than ten clients will hit the page limit first.

#What Stector doesn't do

Better you read it here than find out after signing up:

• No custom domain on status pages. Your page is yourname.stector.app.
• No outbound webhooks, and alert channels are email and Slack only. No SMS, PagerDuty or Opsgenie.
• No keyword or response-body checks. A 200 that serves an error page counts as up.
• No heartbeat or cron monitoring, so a backup job that silently stops running won't be caught.
• SSL monitoring checks expiry only, not chain or hostname validity, and expiry warnings are off until you set how many days ahead you want them.
• Up to 10 status pages, on Business (3 on Pro, 1 on Free), no private pages, no SMS or Slack subscribers.
• No choosing a status page through the API or MCP server. Through the API and the MCP server you can read only your team's oldest status page, and incidents you create through them are posted to that page; to post an incident to another page, create it in the dashboard.

#Who should stay with Statuspage

Stay if any of these is true:

• You need private or audience-specific pages. Private pages start at $79/mo (Starter), and Statuspage sells audience-specific pages on their own pricing model. Stector has no private pages, every page carries "Powered by Stector", and roles are team-wide.
• You need a custom domain. Statuspage lists one from Hobby, $29/mo.
• Your subscribers expect SMS, Slack or webhook notifications, not just email.
• You already run a monitoring tool you trust, and it already feeds Statuspage reliably. You have solved the two-tools problem; switching buys you little.
• Your procurement process favors a vendor that's already approved, and Atlassian is.

Stector fits the other case: a small team that wants the page to change state when the API breaks, without buying and wiring a second tool, and is fine with a stector.app subdomain for now.

Create a free status page. It takes a monitor and a component to see the whole loop work.