Status page for mobile app backends
When your iOS or Android app shows a spinner forever, users leave one-star reviews — even if the bug is a 502 on your API, not the client build. App Store status pages do not cover your Railway or Fly backend.
StillOnline probes your public /health (or auth-free ping route) and hosts a status page at stillonline.tech/.../s/... you can link from support docs and in-app “system status” screens. Telegram owner alerts through the StillOnline bot wake whoever can roll back the API.
Quick answer
For mobile app backends, monitor the API health URL StillOnline can reach from the public internet — not the app binary. Share the hosted status page in help center and support macros; optional in-app WebView to the same URL. Owner alerts: email, StillOnline Telegram bot, or Slack (Telegram guide). Free = one production API URL.
What to check (and what to skip)
| Target | Monitor? | Why |
|---|---|---|
GET /health on API host | Yes | Matches real user failures |
| CDN for static assets | If separate outage domain | Optional second check on Pro |
| Apple / Google system status | No | Not your stack |
| Deep authenticated mobile flows | Usually no | Probes are unauthenticated HTTP |
Design /health to avoid false reds: endpoint design · API-only SaaS.
User-facing copy without an app release
You do not need a store update to be honest during outages.
- Support site — link
stillonline.tech/.../s/...(public guide). - In-app WebView — open the same URL on “Service status” (no custom domain in v1).
- Push notification — manual; StillOnline does not send push to app users.
- Status page subscribers — Google email on the public StillOnline page.
Tell mobile users “our API is degraded” when checks fail — not “update the app.”
Alerts for the on-call developer
Mobile teams are often one backend engineer plus contractors.
- Connect Telegram in settings — official bot, no BotFather (guide).
- Free allows one owner channel; Pro adds Slack and email together.
- Pair with solo on-call without PagerDuty until you hire ops.
Plans as the app grows
| Stage | StillOnline |
|---|---|
| MVP, one API region | Free — single health check |
| iOS + Android + admin API hosts | Pro — multiple URLs / projects |
| CI wants JSON | Pro REST + MCP (REST) |
Related guides
FAQ
Should StillOnline check the mobile app store URL?
No. Store pages do not reflect your API. Probe https://api.yourapp.com/health (or equivalent).
Can StillOnline detect app-only bugs?
Only if they surface as HTTP failures on the checked URL. Client crashes need crash reporting tools — not a substitute for uptime vs page speed.
Where should mobile apps link for StillOnline status?
Help center, in-app WebView, or support email templates — not buried only in footer (B2B trust patterns apply to consumer support too).
Does StillOnline support custom status.yourapp.com for mobile?
No in v1. Use the hosted stillonline.tech/s/... link.
How fast will StillOnline alert when the API returns 502?
After two failed probes in a row (see probe architecture in docs). Allow 2–3 cycles after creating the check before trusting silence.