What happens when a monitor goes down
When a monitor fails two consecutive checks, Uptime Tracker opens an incident, sends alerts to the configured channels, and starts a timeline that records everything that happens until recovery. You do not have to create incidents by hand.
From the incident view your team can:
- Acknowledge the incident to show someone is on it. Acknowledging stops repeat reminders and escalation.
- Assign it to a specific teammate so ownership is clear.
- Open the runbook linked to the monitor, so the responder sees the first steps immediately.
- Add internal notes about what was tried and what was found. Notes stay inside your workspace.
- Post public updates that appear on your status page and go to its email subscribers.
When the monitor passes two consecutive checks, the incident resolves and a recovery alert is sent. The timeline keeps the start time (backdated to the first failed check), acknowledgement, notes, updates and resolution, which makes writing a short post-incident summary much easier.
If you record deployments from CI on Starter or Team, a deploy that happened shortly before the incident is shown next to it as possibly related, which often points straight at the cause. Incident history is kept for 7 days on Free, 90 days on Starter and 365 days on Team.
On-call rotations
On-call rotations on the Team plan define who is responsible for alerts at any given moment, so incidents go to one person instead of everyone. Rotations follow a weekly-style pattern: each member takes a turn, and the handoff happens at a local time you choose, such as Monday at 09:00.
Details that matter in real schedules:
- Local-time handoffs. Handoffs are defined in a time zone, so a 09:00 handoff stays at 09:00 for the team.
- Daylight-saving safe. When clocks change, the schedule does not drift or create a gap in coverage.
- Calendar feed. Each schedule has an iCal feed, so on-call shifts show up in Google Calendar, Outlook or Apple Calendar next to everything else.
Team includes 10 login seats, which is enough for a small rotation of engineers plus a manager. Read-only guest viewers, up to 20 per workspace and limited to a project, can watch status without being part of the rotation.
For a two- or three-person team, a weekly rotation with a Monday morning handoff is a simple starting point. Make sure everyone on the rotation has at least one personal channel configured, such as SMS, Pushover or PagerDuty, in addition to the shared team channel. See alerts and notifications for channel options.
Escalation policies
An escalation policy on Team decides what happens when the first person does not respond: it notifies the next step in order until someone acknowledges the incident or the monitor recovers. This removes the single point of failure of one person's phone being on silent.
A practical three-step policy for a small team:
- Step 1: notify whoever is currently on call through SMS and push.
- Step 2: if nobody acknowledges, notify the secondary engineer or team lead.
- Step 3: notify the whole team channel in Slack or Microsoft Teams.
A policy can repeat up to 5 times, and it stops as soon as anyone acknowledges or the monitor recovers. Teams that already use PagerDuty can send incidents there instead through the Events API v2, with de-duplication so one outage creates one PagerDuty incident.
Escalation is most effective when combined with monitor dependencies, also on Team. When a parent monitor such as your database host or load balancer is down, alerts for the child monitors behind it are suppressed. The on-call engineer gets one clear signal about the root cause instead of a burst of alerts from every service that depends on it.
Maintenance windows
Maintenance windows tell Uptime Tracker that downtime is planned: alerts are suppressed during the window and the time is excluded from availability calculations. Your uptime percentage reflects unplanned outages only, and nobody gets paged for a deploy you scheduled.
Two kinds of windows are available:
| Type | Plan | Typical use |
|---|---|---|
| One-off | All plans | A database migration on Saturday night, a hosting move, a planned upgrade |
| Recurring weekly | Starter and Team | A fixed patch window every Sunday 02:00–03:00 in a chosen time zone |
To schedule a window:
- Choose the monitors or components affected.
- Set the start and end time, or the weekly recurrence and time zone.
Keep windows as short and specific as possible. A window that covers every monitor for a whole night hides real outages that happen to occur during it. You can also manage maintenance windows from the monctl CLI or the REST API, which is handy for opening a window automatically at the start of a deployment script.
Set up incident response for a small team
A workable incident process for a team of two to ten people can be set up in Uptime Tracker in an afternoon.
- Tag monitors by importance, for example
criticalandstandard. - Add a runbook link to each critical monitor: what it checks, the first three things to look at, and who to call.
- On Team, create an on-call rotation and an escalation policy, and point critical monitors at it.
- Route standard monitors to a shared Slack, Teams or email channel with routing rules.
- Create a status page and agree who posts public updates during an incident.
- Schedule recurring maintenance windows for regular patching.
After each significant incident, read the timeline, update the runbook, and adjust thresholds or routing if the alert was too noisy or too late. Team adds an audit log, so changes to monitors and alerting are recorded.
If you are comparing this to a larger incident platform, the comparison pages cover how Uptime Tracker differs from other tools.
What's included on each plan
Every plan includes automatic incidents, acknowledgement and one-off maintenance windows; on-call and escalation are part of Team.
| Free | Starter | Team | |
|---|---|---|---|
| Automatic incidents with timeline | Yes | Yes | Yes |
| Acknowledge, assign, runbook link, notes | Yes | Yes | Yes |
| One-off maintenance windows | Yes | Yes | Yes |
| Recurring weekly maintenance | No | Yes | Yes |
| Repeat reminders, routing rules | No | Yes | Yes |
| On-call rotations, escalation, PagerDuty | No | No | Yes |
| Monitor dependencies, audit log | No | No | Yes |
| Incident history | 7 days | 90 days | 365 days |
Free and Starter suit teams where one or two people handle every alert. Once responsibility rotates between several people, Team's on-call schedules and escalation policies remove the need to agree informally on who is watching each night, and the 365-day incident history supports quarterly or annual reviews.
Try Team free for 14 days without a card; at the end of the trial the workspace returns to Free automatically and nothing is deleted. See pricing.