Getting Started with Monitors

Overview

This guide introduces AppStatus Monitors and covers:

• Monitor types: HTTP, API, Port, and Ping
• SSL certificate monitoring and domain expiry tracking
• Multi-region probing from 70 global locations
• HTTP validation: status codes, response body, headers
• Alert email configuration and incident automation
• Real-time diagnostics and uptime history

What are AppStatus Monitors?

Monitors continuously check the health and availability of your endpoints, services, and infrastructure. They evaluate HTTP responses, TCP port connectivity, SSL certificate validity, and ICMP reachability from multiple global regions and generate state changes that drive alert routing, status communication, and incident workflows.

AppStatus supports four monitor types — HTTP, API, Port, and Ping — each with configurable intervals, timeouts, validation rules, and per-region probe distribution. When a monitor detects a failure, it automatically creates an incident, dispatches alerts through configured notification channels, and updates linked status pages.

Key capabilities:

• 70 global probe regions across North America, South America, Europe, Asia Pacific, Middle East, and Africa
• SSL certificate monitoring with configurable expiry alerts (1–365 days before expiry)
• HTTP validation: expected status codes, response body contains, custom headers
• Real-time diagnostics: DNS resolve, TCP connect, TLS handshake, time to first byte
• Uptime history with 90-day retention and daily summary aggregation
• Pause/resume monitors without deleting configuration

Monitor Workflows

Each workflow maps to real AppStatus features and API endpoints used in the main app.

Troubleshooting

Operational Guidance

• Avoid one monitor serving too many unrelated dependencies.
• Tag monitors by service and owner for traceability.
• Review noisy checks monthly and tune thresholds.

Step-by-Step Setup

A monitor is a recurring health check against one URL or host. You set the target, pick how often to check it, choose which regions to check from, and tell AppStatus how to recognise a healthy response. The dashboard then shows live status, uptime history and any incidents the monitor opens.

1. 1

   Open the Monitors section

   Sign in to the app and use the left-hand sidebar to navigate to Monitors. This is the home for every uptime check in your workspace — both healthy and failing.

   WhereSidebar → Monitors
2. 2

   Click "Create new check"

   The Create Monitor form opens on the right. The form is grouped into three sections — Basics, Validation and Alerting — so you can fill it top-to-bottom in one go.

   WhereMonitors → Create new check (top-right button)
3. 3

   Pick the check type

   Choose what kind of check this is. HTTPS is the right default for most websites and APIs; the other types are for lower-level health checks where HTTP is not appropriate. See the options table below for what each one means.

   WhereBasics → Check type
4. 4

   Fill in the target and timing

   Give the monitor a clear name (it shows up everywhere), enter the URL or host, choose how often the check should run, and how long to wait for a response before giving up. Smaller intervals catch outages faster but use more of your plan quota.

   WhereBasics → Name, URL, Check interval, Timeout
5. 5

   Choose probe regions

   Tick one or more regions where the check will run from. A single failed check from one region is treated as a soft warning; AppStatus only opens a real incident when multiple regions agree the target is down. Pick at least the region closest to your users; pick three or more for production traffic.

   WhereBasics → Regions

   Tip

   The number of regions you can select is bounded by your plan — see the Pricing page for limits.

6. 6

   Set the validation rules

   Tell AppStatus what counts as a healthy response. By default any 2xx status code is considered UP. You can tighten this by requiring a specific status code, or by requiring a token to appear in the response body (great for "I check that the page actually says 'healthy' in it" patterns).

   WhereValidation → Expected status code, Expected response contains, Follow redirects, Verify SSL
7. 7

   Attach alert channels

   Under Alerting, pick one or more notification channels (Email, Slack, SMS, Webhook, etc.) where DOWN and RECOVERY notifications should go. If you have not created a channel yet, click "+ Create channel" right from this dropdown — see the Alerts guide for the channel walkthrough.

   WhereAlerting → Notification channels

   Tip

   You can attach more than one channel — common pattern is Slack for the on-call channel + SMS for the primary responder.

8. 8

   Save and watch the first check come in

   Click Save. The monitor appears in the Monitors list with status "Waiting…" until the first check completes — usually within one interval cycle (60s by default). Click the monitor name to open its detail page with live logs, uptime history and the incident timeline.

   WhereSave (bottom-right) → Monitors list → click the monitor row
9. 9

   Run a Test alert (recommended)

   On the monitor detail page, click the "Test alert" button to fire a synthetic alert through every attached channel. This confirms your Slack webhook, email or SMS configuration works before a real outage depends on it.

   WhereMonitor detail → Test alert (top-right)

Configuration Options

Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.

Feature Reference

Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.

Next Steps

Continue building your monitoring stack: