Setting up uptime monitors

What monitors do

A status page tells your users how things are. Monitors are what find out. Each monitor checks one endpoint on a schedule and records whether it responded, how fast, and whether the answer was what you expected.

Monitors live alongside your status page: go to Engage → Status and switch to the Monitoring tab. The Updates tab next to it is where your incidents and status updates live.

Monitoring needs a status page to attach to. If the project doesn't have one yet, AppGram creates a default page for you the first time you open the Monitoring tab.

Creating a monitor

Click Add Monitor. The form opens in a panel with three sections.

Basic configuration

• Monitor Name — what this check is called, for example API Gateway or Marketing Site.
• Linked Service (optional) — the status page service this monitor represents. Linking is what connects an automated check to the component your users see.
• Monitor Type — pick one of four:
  • HTTP(S) — check a website or API endpoint via an HTTP(S) request.
  • TCP Port — check whether a specific TCP port is open and accepting connections.
  • DNS Record — check whether a DNS record exists and returns the expected values.
  • SSL Certificate — monitor certificate expiry and validity.
• Address — the field adapts to the type. HTTP(S) asks for an endpoint URL such as https://api.example.com/health; TCP asks for host and port such as example.com:443; DNS asks for a hostname.
• Check Interval — how often the check runs: 30 seconds (Premium), 1 minute, 5 minutes, or 10 minutes. The default is 1 minute.
• Request Timeout — how long to wait for a response before treating the check as failed. The default is 10 seconds.

Reliability thresholds

Thresholds stop a single blip from being reported as an outage.

• Failure Threshold — how many consecutive failures before the monitor is marked Down. Default: 3.
• Recovery Threshold — how many consecutive successes before it's marked Up again. Default: 2.
• Expected Status Codes — a comma-separated list of HTTP status codes considered healthy, for example 200, 201, 204. Default: 200. Anything not on the list counts as a failure.

With the defaults and a one-minute interval, a genuinely down endpoint is flagged after roughly three minutes, and recovery is confirmed after two clean checks.

Alerting

See Monitor alerts and automatic incidents for this section in detail.

Managing existing monitors

The monitor list shows each monitor's current state and its last response time in milliseconds. From a monitor's menu you can:

• Pause Monitoring — stop checks temporarily. The monitor shows as Paused and stops alerting. Useful during planned maintenance.
• Resume Monitoring — start checking again.
• Delete Monitor — remove it permanently, along with its check history.

Editing a monitor reopens the same form with its current configuration.

Monitor details

Click a monitor to open its detail view, which shows:

• Current status — up or down, with the time of the last check.
• Uptime (24h) — the percentage of successful checks in the last 24 hours, with the number of incidents detected.
• Average response — response time in milliseconds.
• Response time history — recent checks and how long each took.

Best practices

• Monitor a dedicated health endpoint rather than your homepage. A health check that touches the database catches problems a static page won't.
• Link every monitor to the status page service it represents, so an automated failure maps onto something your users recognise.
• Don't set the timeout shorter than your endpoint's real worst-case response time, or you'll page yourself over normal slowness.
• Add an SSL Certificate monitor for every public hostname. Expired certificates are one of the most common self-inflicted outages, and they're entirely preventable.
• If an endpoint legitimately returns something other than 200 — a 401 on an authenticated route, for instance — add that code to the expected list rather than pointing the monitor somewhere less meaningful.

Permissions

Monitoring requires the status:view or status:* scope, the same as the rest of the status page.