> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Threshold suggestions from observed data

> Once a metric has at least 100 samples in the last 7 days, Observer suggests healthy and unhealthy thresholds grounded in the metric's actual values.

Picking good thresholds is hard. Round numbers (warn at 500ms because
it's round) are either too sensitive (noise) or too lax (real
degradations slip through). Once a metric has at least 100 samples in
the last 7 days, Observer suggests thresholds grounded in its actual observed range, so
you can calibrate to reality instead of guessing.

The suggestion appears on the metric's edit page, beside the threshold
inputs. It is a starting point you apply, adjust, or dismiss. Observer
never changes your thresholds on its own.

## How it works

When you open a metric's edit page, Observer looks at the last 7 days of
that metric's values, excluding samples recorded as unhealthy, and
computes percentiles (p50, p95, p99, and the
low end p5 / p1). From those it suggests bounds based on the metric's
direction:

* **Higher is worse** (latency, error rate, queue depth): healthy under
  the 95th percentile, unhealthy over the 99th. Most values stay
  healthy; only the rare high outliers cross into unhealthy.
* **Lower is worse** (uptime, success rate, remaining quota): healthy
  over the 5th percentile, unhealthy under the 1st.

The panel shows the percentiles and a small distribution bar so you can
see the data behind the suggestion before trusting it.

## Why percentiles

Percentiles are transparent and defensible: "95% of observed values
were under this number" is something you can reason about, unlike an
opaque model output. This is deliberately a simple, explainable v1.
Anomaly detection and seasonal models are not part of it.

## Direction

Observer infers whether higher or lower is worse:

1. From your current threshold operators. If you already set "healthy
   under / unhealthy over", the metric is treated as higher-is-worse.
2. Failing that, from the metric name (latency, error, lag lean
   higher-is-worse; uptime, success, remaining lean lower-is-worse).
3. If neither is clear, no suggestion is shown. The panel asks you to
   set the operators yourself, and the next suggestion calibrates to
   them.

## When a suggestion isn't shown

* **Not enough history.** With fewer than 100 samples the panel says
  so and asks you to set thresholds from your operational targets.
* **TLS certificate metrics.** Days until expiry only counts down, so
  a suggestion from past values would turn degraded within days. Set
  these thresholds from your renewal policy instead.
* **Flat or binary data.** If the values barely vary (for example a
  value that is always `1`, or a count that is almost always `0`),
  percentile bounds would put normal samples outside the healthy
  range, so no suggestion is shown.
* **Unclear direction.** If Observer can't tell whether higher or lower
  is worse and you haven't set operators, it shows no suggestion.

## Trusting the suggestion

The suggestion is based on observed data, not a guaranteed optimum. If
the last week was unusual (a sustained incident, a noisy deploy), the
distribution reflects that. The distribution bar is there so you can
spot a skewed window before you apply. Apply, then adjust the numbers to
match what "healthy" should mean for your service.

## Applying, adjusting, dismissing

* **Apply** writes the suggested operators and values into the form. You
  can still edit them before saving.
* **Adjust** anything by typing over the values.
* **Dismiss** hides the panel for this edit session.

Suggestions are computed from recent data and refreshed periodically;
they are not recomputed on every page load.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.