Users

users_ops_slo_get

Tool

users_ops_slo_get

This product's service-level objectives and how it is doing against them RIGHT NOW: sign-in success rate, refresh error rate and mail-send failure rate, each with the objective, the evaluation window, the sample floor below which it is not judged, and the `users/alert.raised` kind a breach fires. Also returns the raw current window (sign-ins, refreshes, detected token reuse, mail sends) and the product's own trailing sign-in failure baseline — the number the per-product anomaly signal compares a spike against. A `status` of `insufficient_data` is NOT health: it means the window is too quiet to judge. The numbers come from ONE replica's in-process window, so treat them as a spot check rather than a fleet-wide error budget.

Behavior

HTTP: POST /users/ops/slo

Arguments

No arguments.

Response

Field	Type	Always	Description
slos	array	•	Every published objective and its verdict for this window.
scope	string	•	These numbers come from ONE replica’s in-process window, not from the whole deployment. Treat them as a spot check, not as the fleet’s error budget.
window	object	•	The current window, exactly as the alert hook sees it.

Try it

This product's service-level objectives and how it is doing against them RIGHT NOW: sign-in success rate, refresh error rate and mail-send failure rate, each with the objective, the evaluation window, the sample floor below which it is not judged, and the `users/alert.raised` kind a breach fires.

When to use

Example

Ask your agent something like this:

This product's service-level objectives and how it is doing against them RIGHT NOW: sign-in success rate, refresh error rate and mail-send failure rate, each with the objective, the evaluation window, the sample floor below which it is not judged, and the `users/alert.raised` kind a breach fires.

The agent will invoke users_ops_slo_get with these arguments:

{}