Open Status
Common tasks

Common tasks

Procedures for monitoring, incident response, and maintenance.

This guide provides steps for monitoring services and responding to incidents. Console labels are shown in bold.

Before you make a change

Check the organization and environment selectors near the top-left of the console. The organization decides which workspace you are changing. The environment, such as production or staging, filters what you see; it does not move or copy anything.

Your role also matters:

  • Viewers can read information.
  • Members can create and update operational records.
  • Admins manage people, workspace settings, and automation credentials.
  • Owners can also grant ownership.

If a control is missing, ask an admin which role you have. See Roles, members, and teams for the full permission model.

Check service health

  1. Open Overview for a summary, or Monitors for individual checks.
  2. Confirm the environment selector shows the environment you mean to inspect.
  3. On Monitors, use the status filter to focus on down, pending, or paused records.
  4. Select a monitor to inspect its target, current state, recent results, and ownership links.
  5. If a check failed, open its result details. Start with the error message and timing information before changing the monitor.

Down means Status confirmed a failure. A monitor with no decisive result yet shows Waiting (the filter calls this state pending). Paused means scheduled checks are intentionally stopped. If the list is unexpectedly empty, clear the text, tag, folder, status, and environment filters.

For a deeper investigation, follow Test and diagnose.

Monitor a website

You need member access or above.

  1. Open Monitors and select Add monitor.
  2. Start with the Website availability recipe under Templates, or choose the Website / HTTP type.
  3. Enter a recognizable name and the complete https:// address.
  4. Leave the default request method, success range, TLS verification, interval, and retry settings unless your service has a specific requirement.
  5. Add an environment such as production and, when known, an owning team and runbook link.
  6. Choose Test configuration. A workbench run tests the draft without changing public health or opening an incident.
  7. Read any failure message, correct the target or expectation, test again, and save only after the check succeeds as expected.
  8. Return to the monitor list and wait for the first scheduled result. A new monitor can remain Waiting until that result arrives.

Do not turn off TLS verification merely to make a certificate error disappear. That hides a problem visitors may still experience. Use the detailed Monitoring guide for non-website checks, regional policies, credentials, and advanced assertions.

Respond to an incident

You need member access or above to change an incident.

  1. Open Incidents and select the active incident.
  2. Select Acknowledge incident when you take responsibility. This tells other responders that someone is working on it.
  3. Assign a person or team when ownership is known.
  4. Review affected monitors and nearby deployment information. Do not change a deployment relationship until someone has investigated it.
  5. Add an internal note for responder-only context. Never put secrets in a note.
  6. Post a public status update when readers need new information. State what is affected, what users may notice, and when the next update is expected.
  7. Move the incident from Investigating to Identified, Monitoring, and finally Resolved as the facts change. Do not mark it resolved until the service is stable.

Public updates may appear on status pages and reach subscribers. Internal notes and responder discussion remain private. See Incidents for tasks, impact, timelines, automation, and postmortems.

Declare an incident manually

Use this when people report a problem before a monitor detects it.

  1. Open Incidents and select Declare incident.
  2. Enter a short title, the initial public message, and the severity.
  3. Select the affected monitor and status-page components when known.
  4. Create the incident, then acknowledge and assign it from the incident workspace.

Choose severity by user impact rather than anxiety: minor for limited impact, major for broad degradation, and critical for a severe or near-total outage. Follow your organization's own incident policy when it defines stricter rules.

Schedule planned maintenance

You need member access or above.

  1. Open Maintenance and select Schedule maintenance.
  2. Enter a title and a reader-friendly description of the planned work.
  3. Check the displayed organization timezone, then choose the start and end.
  4. Select only the monitors affected by the work. Leaving every monitor unchecked applies the window to all services and has a much wider alerting and public-communication effect.
  5. Use a one-time schedule unless the work truly repeats on a daily or weekly basis.
  6. Review and create the window. Status rejects a conflicting window that overlaps the same monitors.
  7. During the work, add progress updates or extend the end time when needed.
  8. Mark the window complete when work finishes, unless its configured automatic completion safely does that for you.

Maintenance suppresses expected checks; it does not erase an existing incident or pause manual response. See Maintenance for recurrence, status-page visibility, subscriber notices, and worker behavior.

Publish a basic status page

You need member access or above. Decide with your organization which service names and incident details are appropriate for customers.

  1. Open Status pages and select New status page.
  2. Enter the page name and URL slug. Choose Private owner preview while you are building it if it should not be public yet.
  3. Open the Components tab and add components with customer-facing names such as “Website” or “Payments.”
  4. Connect each component to the monitor or monitors that represent its health.
  5. Use Preview to check component order, wording, theme, and the sections you intend to publish.
  6. Configure access, language, and subscriber options for your audience.
  7. Make the page public only after opening its public URL in a separate browser session and confirming that it contains no internal-only information.

A status page does not automatically publish every incident. Incident impact must include components on that page. The full Status pages guide covers impact, history, subscriptions, custom domains, embeds, RSS, password access, and branding.

Find notifications and change preferences

Select the bell in the top bar to open your inbox. You can search it, mark an item read, dismiss it, or open the related record. Use the preferences control in the inbox, or Settings → Notifications, to choose personal delivery categories and browser-push enrollment.

These personal preferences do not change organization alert channels such as email, webhook, chat, or PagerDuty destinations. Admins and responders manage those under Alerts. See Notification center and Alerting.

Undo an accidental deletion

Deleting a monitor, an incident, or a status page sends a snapshot to the recycle bin for 30 days.

  1. Open Monitors → Export → Recently deleted…, or open the Operations toolkit and choose Recycle bin.
  2. Find the item and review its type, original name, and deletion time.
  3. Select Restore. If a name or URL slug is now in use, resolve that conflict before trying again.

A restored monitor returns paused with its configuration intact. Check history, health state, and dependencies are not restored. Some relationships may not be restored when the related record no longer exists. See Recycle bin before relying on restore for a complex recovery.

Troubleshooting

  1. Confirm the organization, environment, and filters.
  2. Check whether your role permits the action.
  3. Read the on-screen error; it usually distinguishes invalid input, a naming conflict, and a permission problem.
  4. Use the top-bar help menu to replay the tour for the current page.
  5. Look up unfamiliar wording in the Glossary.
  6. For a failing monitor, test a draft in the workbench before editing the saved configuration.
  7. If the whole installation appears unhealthy, ask a deployment administrator to check Setup health.

Related documentation