---
title: Monitors
description: Uptime and health checks for HTTP, TCP, UDP, and ping targets.
---

## Introduction

A monitor repeatedly checks whether a target is up, on a schedule you define, and keeps a history of the results. Unlike [serverlet](/docs/serverlet/) or [proxy](/docs/proxy/) metrics, a monitor doesn't have to check something running on Futrou at all — the target can be any HTTP endpoint, host, or port reachable from the monitor's region, on or off the platform.

:::note
Monitors is a project feature and may not be enabled for every workspace yet.
:::

## Creating a monitor

- **Region** — where the check runs from, or **Auto** to let Futrou choose.
- **Name** — used in the dashboard to identify the monitor.
- **Type** — `HTTP / HTTPS`, `Ping`, `TCP`, or `UDP`. See [Check types](#check-types) below.
- **Target** — what to check, in a format matching the type (a URL for HTTP, a host for Ping, a `tcp://host:port` or `udp://host:port` URI for TCP/UDP).
- **Request method** — HTTP monitors only; the HTTP method to send, `GET` by default.
- **Interval** — a 6-field, seconds-leading cron expression, e.g. `*/30 * * * * *` for every 30 seconds.
- **Timeout** — how long, in seconds, to wait for a response before counting the check as failed. Defaults to 10 seconds.
- **Enabled** — whether the monitor is actively scheduled. See [Enabling and disabling](#enabling-and-disabling).

## Check types

- **HTTP / HTTPS** — requests the target URL with the configured method and reports success based on the response. Best for web services and APIs, including a dedicated health-check endpoint.
- **Ping** — an ICMP ping to a host. Confirms basic network reachability without checking any particular service on it.
- **TCP** — opens a TCP connection to `host:port` and confirms it succeeds. Good for checking that a database, cache, or other non-HTTP service is accepting connections.
- **UDP** — the UDP equivalent, for services that communicate over UDP.

## Interval

The interval is a standard 6-field cron expression with seconds as the leading field, rather than the usual 5-field minute-leading form — this is what allows checks more frequent than once a minute (`*/30 * * * * *` for every 30 seconds, `0 * * * * *` for once a minute, and so on).

## Enabling and disabling

A monitor can be toggled without deleting it — **Enabled** on the monitor itself, or the `enable`/`disable` actions from its page. A disabled monitor keeps its configuration and check history but isn't scheduled, so it doesn't run and doesn't count toward alerting until you turn it back on.

## Triggering a check

Use **Trigger** to run a check immediately, outside its normal schedule — useful right after creating a monitor, or to confirm a fix took effect without waiting for the next scheduled interval.

## Checks

The **Checks** tab on a monitor's page shows its recent check history: each entry's status (up/down), latency, timestamp, and any message returned (an error, or the reason a check failed). This is the quickest way to see whether a monitor has been flapping or how its latency trends over time.

## Logs

The **Logs** tab streams the monitor's own log output, separate from its check history — searchable by free-text, and filterable by a time range (`startAt`/`endAt`). A tail view shows the most recent entries (up to 100 by default) without paging through history.

## Deleting

Deleting a monitor removes it and its schedule from Nasua along with its Futrou Cloud record; check history isn't retained afterward.

## Region

A monitor runs its checks from a specific [region](/docs/glossary/#region), or you can leave it on **Auto**. The region determines where the check originates from — relevant if you're checking latency or reachability from a particular geography, or checking a target (like a private region's service) that's only reachable from nearby.

## Pricing

Monitors don't currently carry a separate price — see [Billing](/docs/billing/) for how workspace credit is charged for billed services.