For SaaS teams

Fewer tickets during an outage. More trust after it.

Customers who can see what is happening do not open support tickets about it. Give each of them a page that fits: their components, their channel, their history. Your monitors keep it accurate without a person in the loop.

Free for one monitor. No card needed.

Tidepool statusAcme CorpUpdated 12s ago
All systems operational
Dashboard99.99%
Reporting API99.95%
EU data region100%
45 days agoToday
Get told when something changes
7
Notification channels
365
Days of history
1 : 1
Pages per audience
13
Webhook events

An outage, from the customer's side

What a subscriber sees while your team is heads-down.

09:12

Something feels slow

They open your status page. It already says Investigating, with the component named and a time. They do not open a ticket.

09:15

They subscribe on Slack

One click, their channel, only the components they use. The next update lands there without anyone on your side doing anything extra.

09:48

Resolved, in their channel

The final update explains what happened. The history stays on the page, which is what they will show their own boss.

One page per audience

Enterprise customers on a dedicated region do not need to hear about the shared cluster. Audience-specific pages show each customer the components that apply to them, on a private page if you like, from the same incidents you write once.

  • Audience pages on Starter and up, private pages on Team
  • Custom domain and your branding, or no Status Bee branding at all
  • A year of history per component, the number sales keeps asking for
Tidepool statusUpdated 12s ago
All systems operational
Web app99.99%
Checkout API99.94%
Webhook delivery99.71%
45 days agoToday
Get told when something changes

Subscribers on the channel they actually read

Email, SMS, Slack, Discord, Telegram, Teams or a webhook into their own tooling. Each subscriber picks, and can follow only the components they care about. You are never charged for how many there are.

  • Import your existing notification list
  • Destinations are masked in the dashboard; deletion is self-serve for GDPR
  • Counts per channel, so you know where your customers live
Subscribers1,284
  • Email
    912
  • Slack
    201
  • SMS
    133
  • Webhook
    38
  • m•••••@acmecorp.com2 min ago
  • #status-updates18 min ago
  • +44 ••• ••• 40211 h ago
  • hooks.pagerline.io/…3 h ago

Incidents that open before the tickets do

Link a monitor to each component and set a rule. When a check fails your threshold, the component changes, an incident opens from your template and subscribers hear about it. Your team gets the same alert on their own channel.

  • Draft mode if you want a person to press publish
  • Recovery moves the incident to Monitoring; you write the resolution
  • Every incident and update also goes out as a webhook for your own automation
Checkout APIOutage · 17 min
  1. 02:14:05

    Check failed: HTTP 503 after 1 840 ms

  2. 02:14:35

    Failed again. Two in a row is your threshold, so this is real.

  3. 02:14:36

    Incident opened from the monitor rule: “Checkout errors”, Investigating

  4. 02:14:37

    Posted to Slack #ops, webhook sent to your pager, 912 subscribers emailed

  5. 02:31:40

    Two checks passed in a row

  6. 02:31:41

    Incident moved to Monitoring. You resolve it when you are sure.

What SaaS teams set up first

The page, the check on the app, and the check on the name customers type.

Questions from SaaS teams

Give your customers somewhere to look.

One monitor and a status page, free. No card needed.

Create your status page