Core concepts

What projects, monitors, checks, incidents, alerts, maintenance windows, and status pages are, and how they fit together.

This page defines the nouns the rest of the documentation uses: projects, monitors, checks, incidents, alerts, maintenance windows, and status pages.

#Projects

A project is the container everything else lives in. Monitors, notification channels, maintenance windows, the status page, team members, and API keys each belong to exactly one project. An account can own 1 project on the free plan, 3 on Pro, and 5 on Team.

The plan of the project's owner governs the project. Anything a team member creates inside it counts against the owner's limits and uses the owner's plan.

#Monitors and checks

A monitor describes one thing to watch and how to judge it: a URL, a host and port, a DNS record, or a job that has to check in. A check is one run of that description. Checks run on the monitor's interval, every 5 minutes on the free plan and as often as every minute on Pro and Team.

Each check lands in one of three states:

StateMeaning
UpThe check passed.
SlowThe check passed, but took longer than the monitor's slow threshold.
DownThe check failed: an error, a timeout, an unexpected status, or a failed rule.

Port, DNS, heartbeat, and scheduler monitors never report slow. They are either up or down.

A single failed check does not change a monitor's status. The failure threshold (3 by default) is the number of consecutive failures that confirm a down, and the recovery threshold (1 by default) is the number of consecutive passes that confirm the recovery. Heartbeat and scheduler monitors skip this step: a missed window or a failed run changes their status at once.

#Incidents and the incident policy

An incident is the record of an outage. UptimeX opens one when a confirmed problem has lasted longer than the project's incident policy allows (5 minutes by default) and closes it when recovery has held for the policy's close grace (10 minutes by default). The policy also decides whether slow counts as a problem. By default it does.

The policy times the alerts on every plan. The incident records themselves, with their timeline, updates, and postmortem, are kept on Pro and Team. For the rules, see When alerts fire and Incident policy.

#Alerts and channels

An alert is sent when an incident opens and again when it closes. Push notifications go to the devices the project's owner is signed in to with the UptimeX app. Channels carry the same alert elsewhere: Slack, Discord, a webhook into your own tooling, and, on Pro and Team, email. Channels are added per project on the Notifications page.

#Maintenance windows

A maintenance window is planned downtime. While a window is active, checks for the monitors it covers do not run, so nothing alerts, no incident opens, and the time is left out of the uptime figure. Windows can be one-off or repeat daily or weekly.

#Status pages

A status page is the public view of a project. Visitors see each monitor's current status, a daily history, the uptime percentage, active and recent incidents, and scheduled maintenance, without signing in. Status pages are available on Pro and Team, on an uptimex.co handle or your own domain.

#How it fits together

One account, on one plan, owns projects. Each project holds monitors, and each monitor runs checks on its interval. Consecutive failures confirm a status change, the incident policy turns a lasting problem into an incident, and the incident fires alerts through push and the project's channels and appears on the status page. A maintenance window says in advance that a given stretch of downtime is planned, so none of that happens.

Everything is also an API object

Every noun on this page can be managed with a project API key over the REST API, and monitors can be managed by an AI agent over MCP.