---
title: On-demand checks and URL probes
description: Run a check immediately instead of waiting for the next interval, or test a URL before you commit to a monitor.
sidebar:
  label: On-demand checks
---

{/* Source of truth: packages/shared/src/routes.ts — monitors.check,
    monitors.probe. Hourly limit: maxOnDemandChecksPerHour in
    packages/shared/src/plans.ts. */}

Two things let you get an answer now rather than at the next interval.

## Check now

Runs an existing monitor immediately, using its full configuration — same
regions, same assertions, same timeout. The result is recorded as a normal
heartbeat and can change the monitor's status.

In the dashboard this is the **Check now** button on the monitor. Over the API:

```http
POST /monitors/<monitor-id>/check
```

Use it after deploying a fix, when you do not want to wait out a 30-minute
interval to confirm recovery.

:::note
On-demand checks are rate limited per hour by plan
(`maxOnDemandChecksPerHour` — see [Plans and limits](/billing/plans)). They
count against that budget whether they pass or fail.
:::

## Probe a URL

Tests a URL **without** creating a monitor:

```http
POST /monitors/probe
```

This is the fastest way to answer "would a monitor on this URL work?" before you
commit to one — checking that a health endpoint returns what you think it does,
or that a URL is reachable from Glowo's network at all.

Because there is no monitor, a probe records no heartbeat, affects no uptime,
and triggers no alerts.

## Which to use

| You want to | Use |
| --- | --- |
| Confirm a fix worked, right now | **Check now** on the monitor |
| See whether a URL behaves as expected | **Probe** |
| Design assertions against a real response | **Probe** |
| Recover from a false `DOWN` faster | **Check now** |

:::caution
Neither replaces the interval schedule. A passing on-demand check proves the
service was healthy at that moment; only the scheduled checks tell you whether
it stays healthy.
:::