# account_locked

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](https://www.nauthera.io/docs/v1/runbooks/problems) · Generated from [`internal/runbook/problems.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/problems.yaml) in nauthera-server.