docs Web UI
Web UI
The app is where you add monitors, watch them, and respond when one goes down. On the hosted service it is https://app.uptimepage.dev; on your own instance it is whatever host and port you bound the API to.
Every screen here is a faster way to reach the REST API, not a separate feature set. Monitors and notification channels can also be declared as code with Terraform.
Dashboard
The landing screen after sign-in: summary cards across the top, then one dense table listing every monitor.
The cards give you overall uptime, response time, check volume, and the current up/down split, next to a health rail showing the last 24 hours. The table below carries a row per monitor with its status, type, p50 and p95 response times, a latency sparkline, error rate, and uptime, and you can sort and filter it. It is built to stay readable at a thousand monitors, so the answer to "which one is slow" is a sort rather than a scroll.
Monitors
Monitors lists everything you are checking, with filters by name, tag, and enabled state. Monitors created by an API token or by Terraform carry a small api or terraform chip, so it is obvious which ones a UI edit might get overwritten on the next apply.
Opening a monitor gives you its detail view: current status, uptime figures, response-time percentiles, a breakdown of where the time goes (DNS, connect, TLS, first byte), recent check results, and the incident history. Four time ranges (1 hour, 24 hours, 7 days, 30 days) switch the whole page at once, and if the monitor runs in several regions you can filter any chart down to one of them.
Add monitor takes a URL, an interval, and the regions to check from. HTTP is the default; Monitor types covers the other seven. Two sections are worth a look before you save:
- Detection decides when a failure counts. Set how many consecutive failures open an incident, and how many regions have to agree. See Probe regions for what the region policies mean.
- Notifications binds the alert channels for this monitor, sets how often to remind you while it stays down, and whether recovery is announced. It only appears once your org has at least one channel.
Credentials are not typed into the monitor form. Headers reference org secrets instead, picked with the variable helper, so the literal value lives in one place. See Variables and secrets.
Incidents
Incidents is the responder view: what is open, who acknowledged it, and what has happened since. You can declare an incident by hand for something your monitors cannot see, post updates as you learn more, and close it with a retrospective.
What responders see here is deliberately separate from what customers see on a status page. Incident management covers the model and the workflow.
Settings
| Screen | What you do there |
|---|---|
| Notifications | Add and test alert channels: Slack, Discord, Teams, Google Chat, Telegram, WhatsApp, SMS, email, PagerDuty, ntfy, Pushover, or any webhook. See Notifications. |
| Status pages | Create and publish your public pages, set branding and logo, and choose which monitors appear under which names. See Per-org status pages. |
| Variables | Org-scoped values and write-only secrets that monitors reference as {{key}}. See Variables and secrets. |
| Team | Invite people by email, set roles, resend or revoke pending invitations, and remove members. See Team. |
| Usage | Current versus limit for every quota on your plan, as progress bars. The numbers here are the numbers you are enforced at. See Plans and limits. |
| Account | Export your data as JSON, or delete your account. Deletion is reversible for 30 days by signing back in. |
On-call schedules and escalation policies get their own screens where the feature is enabled.
Sharing a single monitor
A share link opens one monitor's full dashboard for anyone holding the URL, with no account and no operator controls. Credentials are redacted and the view is read-only. Useful for a chat channel or a customer who needs to watch one endpoint. See Share links.
Notes
The UI polls rather than holding a socket open, so leaving a dashboard on a wall display costs one cached query set per refresh regardless of how many screens are watching.
Times render in your browser's timezone, not the server's.