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

NautheraCacheUnavailable

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

One or more nauthera-server replicas cannot use the Redis cache.

Meaning

nauthera_dependency_up{dependency="cache"} has been 0 on at least one replica for a minute. The window is fed by the readiness ping and by every cache read and write requests make, so it also opens for a cache that answers PING but refuses writes (a read-only replica after a failover, a cache out of memory). The cache is a soft check: replicas stay in the Service.

Impact

Relying parties: the grant store fails closed, so authorization codes cannot be redeemed, refresh tokens cannot be used, and DPoP proofs and pushed authorization requests are refused; users finishing a sign-in see the client fail. Security: the brute-force throttle fails open, so sign-in attempts go through unthrottled (the account lock in the database still applies). With rate_limit.backend: redis, each replica falls back to its own rate limit, which loosens limits by up to the replica count.

Diagnosis

  1. Which replicas: nauthera_dependency_up{job="<name>",dependency="cache"}.
  2. The server's view: kubectl -n &lt;ns&gt; logs &lt;pod&gt; | jq 'select(.msg=="dependency is failing" and .dependency=="cache")' (failed_op, error_class, error).
  3. The audit log has system.dependency.degraded for the window, with fails_closed and fails_open listing what the server uses the cache for.
  4. Check Redis with its owner: is the primary up, did a failover leave clients on a replica (READONLY errors), is used_memory at maxmemory?
  5. Rate limiting fallback: nauthera_rate_limit_degraded{job="<name>"}.

Mitigation

  • Restore the cache, or fail over to a healthy primary; the window closes on its own and records system.dependency.recovered.
  • Memory: raise maxmemory. Do not enable eviction: an evicted key is a revocation undone, and the server warns at startup when it cannot confirm Redis never evicts.
  • Topology: use cache.mode: sentinel or cluster so losing one Redis server does not take the cache down.
  • While the throttle fails open, watch NautheraSignInFailureSpike and consider limiting sign-in traffic at the edge.

Escalation

Page the cache owner and the identity platform owner: code exchange and refresh are down for every relying party. If Redis is healthy and other clients use it but the server reports it down, open an issue with the dependency is failing log lines, the cache.* settings (without passwords) and the server version.

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