Documentation

Review your monitoring before launch

Check coverage, alert destinations, and customer communication before relying on a new monitoring setup.

What you’ll accomplish

Your team has verified monitoring coverage and knows how to respond and communicate

In this guide

Check the customer journey

List the services customers rely on: the website, sign-in endpoint, API, or checkout service. Decide what a successful check tells you about each one.

An HTTP check can verify an endpoint response. It does not complete a customer’s shopping journey or prove that every action inside an application works. Choose targets with this boundary in mind.

Workflow walkthrough

Your monitoring readiness check

The right service

Check a URL or service that reflects the customer experience. Verify successful checks and regional coverage in the monitor history.
Three checkpoints before relying on a new monitoring workflow.

Verify the checks

  • Give each monitor a name responders will recognize.
  • Confirm the target and monitor type.
  • Review successful checks in monitor results.
  • Choose regional coverage that reflects where customers use the service.
  • Review timeouts and expected responses so normal behavior does not become noise.

Investigate unexplained failures before increasing thresholds. A configuration change should reflect the service’s intended behavior, not simply hide a symptom.

Agree on the response

Identify the person or team responsible for each critical service. Confirm they have access to the workspace and know where to find the monitor, incident, and check history.

Review alert policies together. Make sure responders understand the difference between a failed check, a confirmed incident, acknowledgment, and recovery.

Use an integration’s test action to check delivery rather than deliberately interrupting a production service. Manage integrations explains the setup path.

Prepare customer communication

If you use a public status page, review it as a visitor. Check component names, descriptions, and the information you expose. Avoid private hostnames and internal implementation details.

Agree who publishes incident updates, what an initial message should contain, and when the next update will be posted. The incident response guide includes a practical message example.

Keep the setup current

Review monitoring after changing domains, endpoints, infrastructure, or team ownership. Retest destinations when credentials or receiving applications change.

Before planned work, review maintenance scheduling. After an incident, use what you learned to improve the target, policy, or response instructions.

Need a hand with this guide?

Tell us where you got stuck. We’re here to help.

Contact us