NautheraServerErrorBudgetBurnSlow
Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program
Public requests fail with a 5xx faster than the monthly error budget allows.
Meaning
The 5xx share of public requests is above 3 times the error budget of
availabilityObjective (99.9% by default) over a day and two hours, or above the budget
itself over three days and six hours. Something fails steadily at a low rate: one route,
one client's requests, a flaky dependency or one unhealthy replica.
Impact
Most users do not notice, but a small share of sign-ins, token requests or admin calls fail, and some relying parties or users may be hit far more often than the average says. Left alone, the month's error budget runs out.
Diagnosis
- Which routes and statuses over the day:
sum by (route, code) (increase(nauthera_.http_ requests_ total\{job="<name>",code=~"5. . "\}[1d])) - Whether one replica stands out:
sum by (pod) (rate(nauthera_.http_ requests_ total\{job="<name>",code=~"5. . "\}[1h])) - Cache and database error rates over the same window:
sum by (op) (rate(nauthera_andcache_ operations_ total{job="<name>",result="error"}[1h])) nauthera_.dependency_ up{job="<name>"} - Read a sample of the failing requests:
kubectl -n <ns> logs deploy/, then follow their<name> | jq 'select(. msg=="http_ request" and . status>=500)' request_id.
Mitigation
- One replica: delete the pod and watch whether the replacement behaves.
- A flaky dependency: fix it with its owner; follow NautheraCacheErrors or NautheraDatabasePoolExhausted if they fire too.
- One route since a release: roll back, or pin the regression for an upstream fix.
Escalation
No page; handle it in working hours. Escalate to the identity platform owner if the cause
is not found within a day. Open an issue when the 5xx come from the server with healthy
dependencies, with the route, status, sample request_ids with their log lines and the
server version (nauthera_build_info).
Alert runbooks · Generated from internal/ and operator/ in nauthera-server.