Manual metrics
When the agent can't measure it, set the status explicitly.
Most Observer metrics are probed: an agent runs a check on a schedule and reports the result. Manual metrics are the escape hatch for signals that have no automation, or where the operator wants to control the status surface explicitly.
When to use a manual metric
- A signal that has no observability today (a third-party SaaS outage, a vendor dependency, an internal system without instrumentation).
- A high-level rollup that should follow operator judgment, not a noisy underlying measurement.
- A service whose status is gated on a contract with a vendor (where Observer should reflect what the vendor says, not what we measure).
What is different
| Aspect | Probed metric | Manual metric |
|---|---|---|
source_type | prometheus, http, tcp, etc. | manual |
| Agent involvement | Agent runs the probe and pushes status. | Agent never sees the metric (filtered at definitions endpoint). |
| Status transitions | Threshold + dwell gating against measured value. | Explicit set via UI / API / incident. |
| Webhook payload | source: "probe" on flips. | source: "manual" or "incident". |
How status flips
Three paths set status on a manual metric:
- Console UI: the metric detail page shows a clickable status pill. Owner-tier users can pick a new status from the dropdown.
- API:
POST /api/v1/metrics/{id}/statuswith{"status": "unhealthy"}. Scope:write:metrics. - Incident impact: when an open incident lists a service that
contains a manual metric, that metric auto-flips to mirror the
incident severity. On resolve, it returns to its last
explicitly-set status (default
healthy).
Threshold model
Manual metrics carry no thresholds. Status is set directly. The
healthy_* / unhealthy_* columns on the metric definition are
ignored; the form hides the threshold section when source type is
manual.
Was this page helpful?