Monitors

Per-day uptime grid for a monitor

Returns a 30-element array describing the monitor's uptime over the last 30 UTC days, ordered today-first. Each entry is computed from monitor_uptime_day (authoritative scheduled count per day) and from down-typed incidents that overlap that day.

pct is null when scheduled = 0 for that day — the dispatcher never tried to check the monitor (account suspended, kill switch on, monitor disabled, dispatcher down, monitor freshly created). The dashboard renders this as the grey/no-data state and must treat null as "no information", NOT as "0%". A pct value of 0 means the monitor was checked and was down for every second of the day.

pct is normally derived purely from down-incident overlap, but is reconciled against monitor_uptime_day.succeeded: a day with zero successful checks is floored to 0 when corroborated as down — an unresolved down incident overlaps the day (any day), or the monitor's current resolved status is down and its current outage (the last down-transition) began before that day ended (only when the monitor is enabled and not currently flapping) — even if the incidents table has no row covering that day (a dropped runtime transition write). A currently-down monitor is floored across every day of its continuous outage, but never a day that predates the current down-period: the down-since timestamp bounds which days the live status describes. It is never floored when the monitor's resolved status is up, so a day where the primary region failed every check but cross-region confirmation kept the monitor up still reads its incident-derived percentage.

flapping incidents are intentionally excluded from the downtime math — uptime semantics treat a flapping monitor as "answering, just bouncing".

Each entry also carries a latency daily candle — open, high, low, close, and average total response time in whole milliseconds, built only from successful checks against the monitor's sticky primary region (wopher's total_ms: the full request round-trip, DNS through last byte of download). latency is null when the day has no successful samples to build a candle from — this includes days predating the feature, and is a distinct null condition from pct (which keys off scheduled = 0): a day can have a non-null pct (fully scheduled, down the entire day) and still carry a null latency. avg is the arithmetic mean of the day's successful-check response times. Latency history is free-tier for every account — no plan gating.

v1 supports window=30d only. The 30-day cap is a visibility and API limit, independent of the 95-day physical retention window for incidents and monitor_uptime_day (see internal/retention/ DECISIONS.md). Wider or narrower windows are out of scope for v1.

get/api/v1/monitors/{monitorID}/uptime

Request

  • Base URL: https://api.uptimemonitoring.com
  • URL: https://api.uptimemonitoring.com/api/v1/monitors/{monitorID}/uptime
  • Auth: HTTP bearer

Path parameters

monitorIDinteger required

Monitor ID.

Query parameters

window'30d'

Window length. Only 30d is accepted in v1.

Response

30-element array of per-day uptime entries, today-first.

daystring date required

UTC calendar day (YYYY-MM-DD).

scheduledinteger required

Number of checks scheduled for this monitor on this day, sourced from monitor_uptime_day.scheduled. 0 means the dispatcher never tried to check this monitor (suspended, disabled, kill switch, dispatcher outage, freshly created).

pctnumber float nullable required

Uptime percentage for the day, derived from down-incident overlap. null when scheduled = 0. Floored to 0 when the day had zero successful checks and the monitor is corroborated down by either signal, both netted against overlapping flapping-incident windows so a flapping monitor's masked-downtime treatment is never overridden: an unresolved down incident whose net (post flap-mask) overlap with the day is greater than zero (any day), or the monitor's current resolved status being down — only when the monitor is enabled, not currently flapping, AND the current status began before the day ended, i.e. the day falls inside the monitor's current continuous down-period. This reconciliation catches days where a runtime incident write was dropped and no incidents row covers the outage — including every day of a multi-week outage, not just the most recent one. A day that predates the current down-period (status flipped down after that day already ended) is never floored by current status alone. Never applied when the monitor's resolved status is up. Always present in the JSON object — never omitted.

Example response

[
  {
    "day": "2026-05-02",
    "scheduled": 1440,
    "pct": 99.86,
    "latency": {
      "open": 212,
      "high": 480,
      "low": 190,
      "close": 220,
      "avg": 231
    }
  }
]

Changes

No recorded changes to this operation across all 1 revision of this API.