Monitors

Uptime monitoring for your endpoints: booboo checks a URL on an interval, alerts your integrations when it goes down, and can chart gauge metrics parsed straight from your health endpoint's JSON response.

Creating a monitor

A monitor needs a name, a URL, and a check interval. You can also set the HTTP method (GET or HEAD), the expected status code (default 200), and a request timeout (1–30 seconds). Check intervals range from 1 minute to 1 hour; the minimum depends on your plan (see Limits).

Creating, editing, pausing, and deleting monitors requires the admin or owner role. All organization members can view monitors and their history.

Checks & alerts

Every check records the status code and response time. A monitor is Up while responses match the expected status code. It flips to Down after two consecutive failed checks — a single network blip won't page you — and recovers on the next successful check.

Both transitions (monitor_down, monitor_recovered) are delivered through your organization-level integrations — Slack, Discord, or a custom webhook. The monitor detail page shows uptime over 24h/7d/30d, a response-time chart, an incident history, and the raw recent checks.

Metric checks

Turn on Capture metrics on any GET monitor and booboo will parse gauge values from the JSON body it already fetches on every check and chart them over time — per monitor on its detail page, and across the whole organization on the Metrics page. Your health endpoint becomes a chart, with no agent or SDK involved.

If your metrics endpoint shouldn't be public, set the optional auth header (a header name plus a secret value) and booboo sends it with every check. The value is write-only: it is never returned by the API or shown in the UI again.

booboo takes one sample per check, so chart resolution follows your check interval — a 1-minute monitor gives you 1-minute charts.

Metrics JSON format

The endpoint must return a top-level JSON object. Every key becomes a named series; the value is either a bare number or an object {"value": n, "limit": n} where limit is optional:

{
  "cpu_load": {"value": 1.3, "limit": 4.0},
  "disk_used_gb": {"value": 31.4, "limit": 40},
  "queue_depth": 7
}

• Values must be plain, finite JSON numbers. Strings, booleans, null, and NaN/Infinity are skipped.
• limit is optional. When present it's drawn as a dashed line on the chart and shown in the "value / limit" readout — useful for things like disk capacity or a load ceiling.
• At most 10 values per monitor are stored per check, taken in alphabetical key order. Keys can be up to 64 characters.
• Invalid entries are skipped silently — a malformed value never fails the check, and parsing never affects the monitor's up/down status.
• Parsed only from successful checks (the expected status code), from the first 256 KB of the response body. GET only — HEAD has no body.
• Gauges only. Values are charted as sampled; rates such as requests per second are not derived. Expose a precomputed gauge if you want one, e.g. {"queue_depth": 7}.

Sanity-check what booboo will see with a plain request:

curl -H "X-Api-Key: your-secret" https://api.example.com/health/metrics

Limits

Retention covers both check history and metric samples. See Billing & Plans for the full plan comparison.