Monitoring Configuration Examples

Choosing the right monitor type is only the first step. The real value comes from configuring checks that match the failure you actually care about.

This guide walks through practical Site, API, and DNS monitor setups you can adapt for your own services.

Last updated: 2026-04-14

How to Use This Guide

Each example includes four things:

1. The monitor type
2. A sample target
3. The validation to add
4. The type of issue the setup helps catch

Use these examples as starting points, then tighten the conditions to fit your own service.

How These Examples Map to the Dashboard

In the current Add/Edit Monitor form, you can apply these examples directly:

1. Choose Site, API, or DNS.
2. Enter the target URL or domain.
3. For API monitors, choose the HTTP method.
4. Use Advanced Request Settings for query parameters, request headers, and any custom request body.
5. Set the interval with the quick picks or the Exact seconds field.
6. Add validation rules that match the success state you care about.
7. Save the monitor and review the first result from the monitors list or edit page.

For Site and API monitors, the dashboard can preview a valid URL while you configure it. If the response looks like JSON, the validation area can also suggest JSONPath conditions automatically.

When you choose POST, PUT, or PATCH, the form also shows a shortcut below HTTP Method that opens Advanced Request Settings for you.

Note: Database appears in the UI as a future dashboard type, but it is not currently configurable from the Add/Edit Monitor form.

1. Homepage Uptime Check

The most basic setup is still one of the most useful.

Monitor type: Site

Example target:

• https://www.example.com

Validation to add:

• Status Code range 200-299

Best for:

• Public websites
• Marketing pages
• Product homepages

Helps you catch:

• Full outages
• Unexpected 5xx responses
• Broken deploys that make the homepage unavailable

2. Careers Page Job Alert

This is a simple way to turn a Site monitor into a practical content alert.

Monitor type: Site

Example target:

• https://company.example/careers

Validation to add:

• Body Contains contains design engineer

You can swap that phrase for the role you want, such as platform engineer, staff backend engineer, or product designer.

Best for:

• Careers pages
• Hiring pages
• Any page where new text matters more than basic uptime

Helps you catch:

• New job postings
• Quiet page updates you would otherwise miss
• Content changes on pages that stay technically online

Pro Tip: The same pattern also works for waitlist pages, launch pages, and pricing pages when you want an alert as soon as specific text appears.

3. Login Page Sanity Check

A page can still be “up” while being useless to real users. This setup checks for the content you expect to see.

Monitor type: Site

Example target:

• https://app.example.com/login

Validation to add:

• Status Code equals 200
• Body Contains contains Sign in

Use ALL (AND) if you want both conditions to match.

Best for:

• Login pages
• Sign-in flows
• Public dashboards with expected text

Helps you catch:

• Redirect loops
• Error pages that still return a response
• Broken page rendering after a release

4. JSON Health Endpoint Check

This is a strong default for APIs where status code alone is not enough.

Monitor type: API

Example target:

• https://api.example.com/health

Validation to add:

• Status Code range 200-299
• JSONPath $.status equals ok

Use ALL (AND) for a strict health check.

If the dashboard preview detects JSON, it can often suggest the first JSONPath keys for you automatically. Use those as a starting point, then tighten the condition to match your actual success value.

Best for:

• Health endpoints
• JSON APIs
• Application-level readiness checks

Helps you catch:

• APIs that still return 200 but report an unhealthy state
• Partial outages
• Broken application logic hidden behind a successful HTTP response

Guide: Advanced API Monitoring with JSONPath

5. Authenticated Internal Readiness Check

Some of the most useful API checks require auth headers or request customization.

Monitor type: API

Example target:

• https://api.example.com/internal/ready

Request setup:

• Open Advanced Request Settings
• Add the required auth header
• Add any required query parameters or request body values

Validation to add:

• Status Code equals 200
• JSONPath $.ready equals true

Best for:

• Protected health endpoints
• Internal readiness checks
• Service-to-service verification

Helps you catch:

• Broken auth on internal checks
• Dependency failures surfaced by readiness endpoints
• Services that are reachable but not truly ready

6. Response Header Verification

Headers can be a useful validation target when body text alone is not enough.

Monitor type: API

Example target:

• https://api.example.com/v1/status

Validation to add:

• Header content-type contains application/json

You can use the same approach for other predictable response headers when your service returns them consistently.

Best for:

• APIs where content type matters
• Reverse proxy validation
• Release checks that depend on known headers

Helps you catch:

• Wrong content types
• Edge or proxy misconfiguration
• Unexpected routing behavior

7. Domain Migration Verification

DNS monitoring is useful when the important question is where traffic resolves, not what the page body says.

Monitor type: DNS

Example target:

• example.com

Validation to add:

• Expected A record
• Expected AAAA record
• Expected CNAME target

Choose the record type that matches your setup.

Best for:

• DNS migrations
• Failover checks
• Critical domains

Helps you catch:

• Wrong DNS targets after provider changes
• Incomplete cutovers
• Traffic resolving to the wrong infrastructure

8. Mail Routing Verification

Email delivery can fail quietly when DNS mail records change unexpectedly.

Monitor type: DNS

Example target:

• example.com

Validation to add:

• Expected MX records

Best for:

• Support inbox routing
• Transactional email domains
• Provider migrations

Helps you catch:

• Missing mail-routing records
• Incorrect DNS changes
• Email delivery issues caused by DNS rather than app failures

Quick Pattern Guide

What Makes a Good Monitor Configuration?

A useful monitor does more than ask whether something responds.

Good configurations usually do at least one of these:

• Confirm the response contains the right content
• Confirm structured fields match the expected state
• Confirm the response stays within an acceptable latency range
• Confirm DNS still points to the correct destination

In other words, monitor for the success state you actually care about.

If you are setting up a monitor from scratch, start with one clear success rule first, confirm it behaves the way you expect, then add stricter conditions only when they materially improve signal quality.

Guide: Advanced Expected Conditions

What’s Next?

• Learn about monitor types
• Set up your first monitor
• Use advanced expected conditions
• Advanced API Monitoring with JSONPath