Mobile app
What the mobile app shows, and how push notifications get set up. View-only, no CRUD.
Mobile app
The up0 mobile app (React Native + Expo, iOS and Android) is view-only: every create, edit, and delete action lives in the console. The mobile app exists to show you status and incidents wherever you are, and to carry push notifications to your device.
No screenshots yet
This page was written from the app's source and mobile/CLAUDE.md, not
from a running build: no physical device or simulator was available in
this session. Screenshots are pending a device walk; nothing below is
guessed at, but nothing is illustrated either.
Signing in
The app authenticates the same way the console and CLI do: Zitadel OIDC,
PKCE, no client secret (expo-auth-session). There is nothing
mobile-specific about the login itself beyond the callback scheme
(io.up0.uptime://callback). Sign in once, and the app stays signed in
with the token refreshed automatically in the background.
The four screens
A first-run shows a short onboarding carousel; every run after that opens straight to a three-tab bottom navigator, with sign-in gating both.
Onboarding
A first-launch-only carousel introducing the app, stored as a flag in local storage so it never appears again on that device. It ends in Get Started or can be skipped straight to sign-in.
Dashboard (Monitors)
The default tab after sign-in. A list of every monitor in your organization, each row showing its current status and uptime percentage, colour-coded (green at 99%+, yellow in the 95–99% range, red below that). Tapping a monitor expands a 7-day liveness graph built from the same check data the console's monitor detail page uses. Pull-to-refresh reloads the list; there is a filter to show only monitors currently down.
Incidents
Incidents from the last 7 days, pull-to-refresh like Dashboard. An empty state reads "No incidents in the last 7 days. Your services are running smoothly." rather than a bare blank list.
Profile
Account information, a push-notifications toggle, a Test Notification button (useful for confirming push actually reaches the device before relying on it), links to Help & Support and the Privacy Policy, and Sign Out.
None of the four screens offer create, edit, delete, acknowledge, or resolve actions on monitors or incidents; those stay in the console. The one interactive exception is push-notification action buttons themselves (see below), which are a notification-delivery mechanism, not an in-app CRUD surface.
Push notifications
Device registration happens automatically once you are signed in and have
granted the OS notification permission; there is no separate opt-in screen
beyond that permission prompt and the Profile toggle. Under the hood this
registers an Expo/FCM token with the backend
(POST /device-tokens), the same push path the notification schedule in
the console's Notifications page
controls per member.
You are notified when an incident opens and again when it resolves. Some incident notifications carry native action buttons (acknowledge / resolve from the notification itself, without opening the app) when the app has already registered the matching action category with the OS. This depends on the notification having reached the app at least once while it was running (foreground or backgrounded-but-alive) so the category could be registered; a cold, never-seen-before action set on a fully killed app will not show buttons the first time.
Push does not work in a simulator
Firebase Cloud Messaging needs real device hardware. The app's own error handling says so directly if you try Test Notification in a simulator.
What the app does not do
Everything else in this documentation (creating monitors, managing members and roles, configuring rules and escalation policies, viewing dashboards and the query explorer) is console- and CLI-only. If you are looking for a mobile equivalent of any of those, there isn't one; the app's whole job is read-only visibility plus push delivery.