Skip to main content
If you do not have a Prometheus server, no observability for the target system, or want a status surface that follows operator judgment rather than a measurement, manual metrics are the right shape.

​
Steps

1

Create the metric

Manual metrics are created with config as code. The console’s Source type picker does not offer a manual type. Add a metric with source_type: manual and an empty source_config to your config document:
observer.yaml
Apply it with the CLI (observer apply -f observer.yaml) or POST /api/v1/config/apply. Manual metrics need no agent and no thresholds; nothing collects or evaluates a value for them.
2

Set the initial status

Set the status with POST /api/v1/metrics/{id}/status (the request is shown in the last step). Find the metric’s id in the console or with GET /api/v1/metrics. Pick the right initial status (healthy is the most common).
3

Bind the metric to a service and (optional) SLO

Manual metrics fit the same service / SLO model as probed metrics. Open the service, define an SLO that points at the manual metric, set a target, and the budget will burn whenever the metric is in the unhealthy state. The machinery is the same as a probed metric.
4

Hook up automation (optional)

For systems with their own observability, you can drive a manual metric from outside Observer:
The scope write:metrics is required. note is optional (a string, or null for none) and ends up in the audit log.
Incident-driven statusWhen an open incident lists a service with an SLO on a manual metric, that metric auto-flips to mirror the incident’s severity. This is intentional: manual metrics have no probe, so the only meaningful signal is what the operator says is true. See Manual metrics for the full semantics.