account_locked

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

The account is temporarily locked after repeated failed sign-ins (429).

#Meaning

Sent by POST /v1/auth/sign-in only when auth.brute_force.reveal_lockout is on. After auth.brute_force.max_failed_attempts failures the account is locked for lockout_duration, doubled for each further failure when lockout_backoff is on, up to lockout_max. While locked, every attempt is refused, including the right password. An address no account holds locks the same way, so the answer does not say whether the account exists. instance carries the hosted /account-locked page.

#Impact

The user sees "Account temporarily locked". It is expected after repeated wrong passwords. If it happens to a user who did not try, someone else guessed at the address.

#Diagnosis

1. Look the request id up on the Troubleshooting page. The lock is recorded as auth.account.locked with attempts, locked_until and limit_scope.
2. nauthera_auth_account_lockouts_total counts locks across the fleet.

#Mitigation

• As a user: wait and try again, or reset the password, which clears the lock.
• As a support agent with users.lifecycle: unlock with POST /v1/admin/orgs/{slug}/users/{id}/unlock and a reason, after confirming who is asking.
• As an operator: tune auth.brute_force.*; turning reveal_lockout off answers locks as too_many_requests instead.

#Escalation

Escalate when locks appear without failed attempts in the audit log, or do not lift after locked_until. Open an issue with the request id, the auth.account.locked record and the server version.

Problem code runbooks · Generated from internal/runbook/problems.yaml in nauthera-server.