---
title: Monitors
description: What a monitor is, the eight types Glowo can run, and the settings every monitor shares.
sidebar:
  label: Overview
---

{/* Source of truth: packages/shared/src/monitors.ts — MonitorTypes,
    MonitorStatuses, MonitorIntervals, createMonitorBaseSchema. Re-read it
    before changing any number on this page. */}

A **monitor** is one thing you want watched: a URL, a host and port, a DNS
record, or a job that is supposed to check in. Glowo runs the check on a fixed
interval from one or more regions, records every result, and decides when the
result is bad enough to tell someone about.

## The eight types

<CardGroup cols={2}>
  <Card title="HTTP(S)" href="/monitors/http" icon="link">
    An HTTP request, its status, timing and body. Websites, APIs, health
    endpoints.
  </Card>
  <Card title="TCP" href="/monitors/tcp" icon="plug">
    A TCP connection opens on a host and port. Databases, message brokers,
    SMTP.
  </Card>
  <Card title="Ping" href="/monitors/ping" icon="radio-tower">
    ICMP echo reaches a host. Servers, routers, anything without a port to
    speak to.
  </Card>
  <Card title="DNS" href="/monitors/dns" icon="network">
    A record resolves, optionally to an expected value. Delegation, MX records,
    failover records.
  </Card>
  <Card title="DNS Diff" href="/monitors/dns-diff" icon="git-compare">
    Whether a DNS answer has *changed* since last time. Detecting hijacks and
    unplanned record edits.
  </Card>
  <Card title="WebSocket" href="/monitors/websocket" icon="cable">
    A WebSocket connects, and optionally echoes a message. Realtime backends,
    chat, live feeds.
  </Card>
  <Card title="gRPC" href="/monitors/grpc" icon="waypoints">
    The standard gRPC health protocol answers *SERVING*, or the endpoint
    speaks gRPC at all. Microservices, internal APIs.
  </Card>
  <Card title="Push" href="/monitors/push" icon="heart-pulse">
    That something called *you* within a grace period. Cron jobs, backups,
    batch pipelines.
  </Card>
</CardGroup>

The type is fixed when you create the monitor. Everything else can be edited
later.

## Statuses

| Status | Meaning |
| --- | --- |
| `UP` | The last confirmed result was good. |
| `DOWN` | The check failed, confirmed. Alerts fire on entry. |
| `DEGRADED` | Reachable but not healthy — a `warn` assertion failed, or a response-time threshold was crossed. |
| `CHANGED` | DNS Diff only: the answer changed. Needs acknowledging. |
| `MAINTENANCE` | Inside a maintenance window. Checks still run; alerts are suppressed. |
| `PENDING` | Created but not yet checked. |

A failing check does not immediately mean `DOWN` — see
[Confirmations and flapping](/monitors/confirmations).

## Settings every monitor shares

| Setting | Allowed values | Default |
| --- | --- | --- |
| `name` | 1–255 characters | — |
| `interval` | one of **30, 60, 120, 300, 600, 1800, 3600** seconds | — |
| `retries` | 0–10 | 3 |
| `timeout` | 1000–60000 ms | 10000 |
| `tags` | up to 20 tags, 50 characters each | none |
| `description` | up to 1000 characters | none |
| `regions` | up to 32 selected from the [available regions](/monitors/regions) | plan default |
| `regionStrategy` | `all`, `round_robin`, `random` | `all` |
| `confirmationsRequired` | 1–5 | 2 |
| `recoveryConfirmationsRequired` | 1–5 | 2 |
| `minFailureDurationMs` | 0–300000 ms | 30000 |
| `notificationChannelIds` | up to 50 channels | none |
| `projectIds` | up to 20 projects | none |

:::note
The 30-second interval and multi-region checks are plan-gated. See
[Plans and limits](/billing/plans) for what your plan allows.
:::

## Pausing

Pausing a monitor stops its checks and its alerts, and excludes the paused time
from uptime calculations. It is the right tool for planned work you did not
schedule in advance; for planned work you *did* schedule, use a
[maintenance window](/status-pages/maintenance-windows) instead so the status
page explains the gap to your users.