llms.txt
Search Documentation
Search through all documentation pages
Core Concepts

Monitors Overview

Choose the right monitor type and understand how monitor status is computed

Monitors are checks that run on your schedule and write a status + latency sample. Use this page to pick the right monitor type and understand status behavior.

Status values

Kener monitor results can be:

  • UP: Check succeeded
  • DEGRADED: Check succeeded but is unhealthy by your logic/threshold
  • DOWN: Check failed
  • MAINTENANCE: Overridden by an active maintenance window
  • NO_DATA: No signal yet (mainly used by heartbeat monitors before first ping)

Status priority

Final status is resolved by priority:

MAINTENANCE > INCIDENT > REALTIME > DEFAULT

So realtime checks do not override an active maintenance or incident state.

Scheduling

Monitors run from cron expressions (for example * * * * * for every minute). Use tighter schedules for critical services and relaxed schedules for low-risk dependencies.

Uptime calculation

Default uptime formula:

      UP + MAINTENANCE
-------------------------------- x 100
UP + MAINTENANCE + DEGRADED + DOWN

Monitor types

Stored secrets

The dashboard and the REST API show these stored values as ********: each header value, the request body, the proxy URL, a SQL connectionString, a Docker tlsKey, and a heartbeat secretString. Monitor checks use the real values.

  • The dashboard shows the heartbeat secret to users with monitors.write, so they can copy the heartbeat URL.
  • A save that sends ******** back keeps the stored value. To change a secret, type the new value.
  • A $SECRET reference such as Bearer $API_TOKEN is masked too. The value stays in the environment variable.