LiveStatus
Back to blog
#product#mobile#incident-response

Why we built a mobile app for status pages

Email alerts go to spam. People check their phones. Here's why LiveStatus ships a native mobile app and why no one else does.

Andrew Leonenko··6 min read

Here's the pitch in one sentence. Every status page company forgot that the people watching your status page are holding a phone.

I started LiveStatus because I kept missing incidents. Not mine, other people's. I'd be out at dinner, a vendor I depended on would go down, and I'd find out two hours later when I opened my laptop to an inbox full of angry messages from my own customers. The vendor had a status page. They'd posted updates. I just never saw them, because their "notification" was an email that got buried under 40 other emails, half of them marketing drip sequences.

I'm not unusual. If you survey any engineering team about how they find out about vendor outages, the honest answer is "my customer tells me" or "Twitter". The status page is almost never the source. And that's insane, because the status page is the one tool literally designed for the job.

So I asked: why doesn't this work? And the answer is the same every time. The big three status page tools (Statuspage.io, Instatus, Better Stack) all have exactly one way to notify you: email, plus maybe a webhook if you're on a paid tier. That's it. No push. No real app. You're supposed to trust that an email about a production outage is going to beat the 50 other emails fighting for your attention.

It does not.

The email problem, said out loud

Email is fine for receipts. It's terrible for interrupts. A few things break down once you start depending on it for incident alerts:

  1. Gmail routes transactional mail wherever it feels like. One week a vendor's alerts land in Primary, next week they're in Updates, the week after they get flagged as promotional because the template changed. You can't build a reliable process on that.
  2. People don't check email during dinner. They check their phone. That's two different behaviors. Email is a "when I sit down at my desk" thing. Incidents don't wait for that.
  3. There's no urgency signal. A new email from noreply@vendor looks identical to a new email from noreply@vendor about a billing reminder. You can't tell one is "your entire API is on fire" and the other is "your invoice is ready". Push notifications can.
  4. Deliverability is a black box. If your SPF record drifts or your sending domain gets on a greylist, alerts silently stop. You won't notice until the postmortem.

Webhooks help if you're a platform team that's already wired up PagerDuty or Opsgenie. They don't help if you're a PM who needs to know that Segment is having issues so you can warn the sales team before the demo at 2pm.

What a phone can do that email can't

Push notifications are not magic. They're just the interrupt channel that actually works because iOS and Android prioritize them, because users see them on the lock screen, and because the OS enforces delivery instead of trusting a spam filter.

With LiveStatus you subscribe to a vendor's page the same way you'd subscribe to email. You pick which services you care about. And you get a push the second they mark something degraded. Lock screen. Badge on the app icon. Optional critical alerts for sev-1 stuff so it cuts through Do Not Disturb (we use this one carefully, only for incidents flagged as major outage).

The app itself is a plain list of pages you're watching and a plain list of active incidents. No social features, no feed, no rewards. It's a tool. You open it, see what's broken, close it. I think that's why people like it. It respects the job.

Why this was a free win

Here's the weirdest part of building LiveStatus. The mobile app is maybe 15% of our engineering effort. It took me a few weeks with Expo and a couple of App Store review rounds. It's not a moonshot. Any of the incumbents could ship this in a quarter if they wanted to.

But they don't. I've thought about why for a while, and I think the real answer is that Statuspage.io is owned by Atlassian, Instatus is a lean bootstrapped team that's allergic to native code, and Better Stack sells to SRE teams who already live in PagerDuty, so mobile alerts are "someone else's problem". Each one has a rational reason to skip it. And collectively they left a gap the size of a house.

That's the whole founding story of LiveStatus, honestly. I wasn't trying to out-engineer anyone. I just noticed that the one thing users were asking for on every forum thread was a mobile app, and every existing vendor had a rational business reason not to build it. So I did.

What this changes about incident response

Once push notifications work, a few things get better downstream:

  • Mean time to awareness drops from hours to seconds. I've measured this on my own team. We went from "I found out from a customer" to "my phone buzzed before the customer did" on every outage we've tracked since we started dogfooding.
  • You stop needing a dedicated NOC. If everyone on the team has the app, the on-call rotation becomes lighter because you have N redundant humans who will all see the incident at once.
  • Vendor incidents become scheduleable. If AWS us-east-1 is degraded and I know about it immediately, I can delay a risky deploy by an hour. That's money.
  • Postmortems get more honest. When the log says "status page was updated at 14:03" and your phone buzzed at 14:03, you can't hand-wave about communication delays.

We're not the only people who've noticed this. Uptime Robot has some push support in their mobile app. PagerDuty has one obviously. But none of the big public status page tools do it, and that's the specific gap LiveStatus fills.

Where we're going with it

The short roadmap, in order:

  1. Critical alerts that bypass Do Not Disturb, gated to paid tiers so we don't annoy people. Shipped.
  2. Widgets on iOS and Android for "status at a glance" without opening the app. In review.
  3. An Apple Watch complication that shows a dot for each service you watch. Green, yellow, red. Prototyping.
  4. Shared incident threads so teammates can discuss an ongoing outage inside the app without jumping to Slack. Thinking about it.

None of this is novel. It's just the obvious stuff that nobody has bothered to do because they all assumed email was good enough. It isn't.

If you run a status page on any of the big tools and you're tired of finding out about your own incidents from customers, import your existing page in 30 seconds and try the app. Free tier works fine. I'll know when you do, because my phone will buzz.

More posts