Monitoring setup

Use an active check for endpoints and a heartbeat for recurring work.

The two monitor types have separate creation paths because they answer different questions: can LatidoFlow reach the endpoint, or did the external workload finish correctly?

Active monitoring

Create an uptime monitor

1. Open Uptime monitors → New uptime monitor. Enter a descriptive name and a public HTTPS endpoint. Local, private, unresolved, credential-bearing, and metadata-service targets are rejected.
2. Choose the cadence. Checks can run every 5, 10, 15, 30, or 60 minutes. The request timeout cannot exceed 30 seconds.
3. Define success. HTTP 200 is the default. You can instead accept explicit status ranges and add body text, strict JSONPath, freshness, or numeric-tolerance rules. Every configured rule must pass.
4. Set alert confidence. Choose the N failures among M samples required to confirm an outage, the recovery threshold, optional trusted probe locations, dependency monitors, and flapping controls.
5. Queue a probe. From the list or monitor detail page, queue a real check and wait for its run evidence. Configuration and infrastructure failures remain visible without being counted as target downtime.

Endpoint credentials

Keep credentials out of the URL. Add one supported request header; its value is encrypted and never shown in configuration exports. Use Replace endpoint credentials for a clean URL or a new header value.

Response privacy

Raw response bodies are not stored. Run evidence keeps bounded metadata such as byte count, hash, content type, and safe rule-result previews.

Passive monitoring

Create a heartbeat monitor

1. Open Heartbeats → New heartbeat. Name the recurring job, worker, queue task, webhook flow, or automation.
2. Set the expected interval, grace period, and run timeout. The first accepted completion arms the timer; later completions establish each next expected window.
3. Add an outcome contract when exit status is not enough. Flat numeric assertions can require a minimum, maximum, or exact value. Structured semantic checks can inspect JSONPath values, freshness, tolerance, or weekday and weekend baselines.
4. Copy the monitor's secret ping URL or use the bearer-authenticated runtime API. Store the credential in the workload's secret manager. Use POST when sending output or structured evidence.
5. Run the real workload. Confirm the monitor detail page shows the expected run and health state. A valid later completion can recover health while its original early, grace, or late classification remains available for diagnosis.

curl -X POST "https://www.latidoflow.com/heartbeat/{monitor_uuid}/{token}" \
  -H "Content-Type: application/json" \
  -d '{
    "output": {"records_processed": 42},
    "evidence": {
      "records_processed": 42,
      "completed_at": "2026-08-09T12:00:00Z"
    }
  }'

Do not put a bearer token, raw exception, customer record, authorization header, or request payload into metadata, output, evidence, or logs.

Operate and change a monitor

Pause or resume

Use the monitor list. Pausing stops scheduled evidence collection and alerting for that monitor; resume only when the target is ready.

Inspect evidence

Open the detail page for current health, recent runs, logs, setup health, schedule preview, incidents, and status-page links.

Verify configuration

Use the isolated simulation to inspect scheduling and rule behavior. Then use a real probe or natural workload execution for operational proof.

Manage as code

Export YAML, PHP, or JSON, review it in version control, and import reviewed JSON or YAML when definitions change. Omitted optional contracts preserve their current values; documented clear values remove them.

Check capacity

The Billing page shows the current plan, monitor limit, and retention window. Monitor creation stops at the enforced capacity.

Create uptime monitor Create heartbeat Runtime API setup