HTTP API

Uptime checks and heartbeat pings stay separate.

Use uptime monitors when LatidoFlow should queue public HTTPS probes and require HTTP 200. Use heartbeat completion pings when an external cron job only needs to report successful completion.

GET  /heartbeat/{monitor_uuid}/{token}
POST /heartbeat/{monitor_uuid}/{token}
{
  "metadata": {
    "batch": "nightly-2026-06-30",
    "records": 42
  }
}

POST /api/v1/monitors/{monitor_uuid}/runs/start
POST /api/v1/runs/{run_uuid}/heartbeat
POST /api/v1/runs/{run_uuid}/success
POST /api/v1/runs/{run_uuid}/fail
POST /api/v1/runs/{run_uuid}/logs

Heartbeat monitors start timing after the first successful ping. Each later success ping resets the next expected window, and JSON or query-string metadata is stored on the run after secret redaction.

Uptime monitors

Uptime monitors queue bounded public HTTPS checks, expect HTTP 200, confirm an initial target failure with one delayed attempt, and open an incident only when both target attempts fail.

Setup verification

Monitor detail pages include a setup health checklist, schedule preview, grace-time explanation, and an isolated simulation. Definition verification and simulations do not count as external execution proof.

Queue metadata

Start events accept queue_connection, queue_name, and sanitized metadata for job-level debugging.

Definition safety

The UI, API sync, and monitoring-as-code import enforce one uptime definition contract. Sensitive URL query credentials and reserved transport headers are rejected. Execution URLs and optional header values are encrypted at rest, configuration output stays redacted, and authorized operators rotate legacy credentials on a dedicated page before queuing a verification probe.