Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

NautheraServerNoReplicasAvailable

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

The nauthera-server Deployment has no available replica.

Meaning

kube-state-metrics reports kube_deployment_status_replicas_available 0 for the Deployment while it asks for at least one replica, for five minutes. No pod is Ready, so the Service has no endpoint. The usual cause is readiness failing everywhere, because the database is unreachable (/readyz fails without it), or pods that cannot start: a failed rollout, a refused configuration, an image that cannot be pulled, or pods that cannot be scheduled.

Impact

Full outage: no user can sign in, no token is issued or refreshed, and the admin API and dashboard are down for every relying party and administrator. Tokens already issued keep working at resource servers that validate them offline against a cached JWKS.

Diagnosis

  1. Pod states: kubectl -n <ns> get pods -l app.kubernetes.io/name=nauthera-server and kubectl -n <ns> describe deploy <name>.
  2. Running but not Ready: kubectl -n <ns> port-forward pod/<pod> 9090:9090 and curl -s localhost:9090/readyz; checks.database unhealthy means NautheraDatabaseUnavailable.
  3. Not starting: kubectl -n <ns> logs <pod> --previous for a refused configuration; kubectl -n <ns> get events --sort-by=.lastTimestamp for image pulls, scheduling and quota.
  4. With appendOnlyAudit, a pod refuses to start while a migration is unapplied or no audit partition covers this month; its log names nauthera-server maintain.

Mitigation

  • Database: follow NautheraDatabaseUnavailable.
  • Bad rollout: helm rollback <release>.
  • Refused configuration: fix the value the startup log names and roll out again.
  • Missing migration or partition with appendOnlyAudit: run kubectl -n <ns> create job --from=cronjob/<name>-maintain <name>-maintain-manual.
  • Scheduling or quota: free capacity or adjust the requests.

Escalation

This is a full outage of sign-in. Page the owner of the identity platform at once, and the database owner when readiness fails on the database. If pods crash on a configuration they accepted before, open an issue with the crashed container's log and the server version.

Alert runbooks · Generated from internal/runbook/alerts.yaml and operator/internal/runbook/alerts.yaml in nauthera-server.