okta error e0000060 locked out too many requests

Recover from Okta E0000060 lockout after too many requests

TL;DR

E0000060 is the lockout event Okta logs when an account gets locked after too many failed requests. Unlock the user in the admin console, but before you do, find what hammered the account - a stuck script with a stale credential, a misconfigured integration retrying forever, or a genuine attack - and stop it. Unlocking without removing the cause just re-locks the account within minutes.

The error

Okta System Log: user.account.lock  -  Outcome: FAILURE/SUCCESS
Result code: E0000060 (locked out: too many requests)
Preceded by a burst of E0000004 authentication-failed events for the same user

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=okta%20error%20e0000060%20locked%20out%20too%20many%20requests"

Fix it

Step 1: Identify the source of the failure burst

In Okta Admin / Reports / System Log, filter by the locked user and look at the minutes before the E0000060 event. Note the source IPs, client types, and request rate.

Expected: one source dominates the burst. A single IP hammering at machine speed is a script or an attack, not a human typing a password.

Step 2: Stop the offending client before unlocking

Stuck script: rotate the stale credential or kill the job. Misconfigured integration: fix its retry logic. Unknown external IP: block it at the network edge or tighten the sign-on policy for the zone.

Expected: the failure burst stops in the system log. Do not unlock while the burst is still running.

Step 3: Unlock the account

In Okta Admin / Directory / People / [user] / More actions / Unlock account. For API-driven unlocks, use the user lifecycle unlock endpoint with an admin credential.

Expected: the user status returns to active and the lock event clears.

Step 4: Review the lockout policy thresholds

Open Security / Authentication / select the password policy / lockout settings. Check max attempts and lockout duration.

Expected: you can say whether the threshold is sane. Overly tight thresholds turn every script hiccup into a lockout; overly loose ones weaken the defense.

Step 5: Confirm clean login and no re-lock

Have the user log in normally, then watch the system log for ten minutes for any new failure burst.

Expected: successful logins, zero new E0000004 bursts, no second E0000060.

When this applies

• The system log shows E0000060 for a user or service account
• An account keeps re-locking after being unlocked
• A burst of failed logins precedes the lockout

When it doesn't

• Single failed logins with no lockout (normal auth failure)
• Admin-deactivated accounts (different state, different fix)
• MFA push fatigue without lockout (policy issue, not lockout)

Compatibility

Okta password policies and account lockout behavior. Applies to user and service accounts.

Variant phrasings

okta account locked too many failed attempts

Same mechanism. The fix is always unlock plus remove-the-cause, in that order.

okta unlock user e0000060

Unlock from Directory / People. If the API is preferred, the lifecycle unlock endpoint does the same thing.

Why it happens

Lockout is a defensive mechanism: Okta counts consecutive failed authentication requests and locks the account past the policy threshold. The lockout is working as designed. The real problem is whatever generated the burst - usually automation with a dead credential retrying at full speed, fast.

Edge cases

• Service accounts lock too, and they have no human to notice; alert on their lockouts
• Unlocking via API needs an admin-level credential with user-management scope
• Smart lockout vs hard lockout behave differently across sign-in flows; check which policy applies

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjPiYneIi6I1bEjmUMJLeQ

Resolved from the public thread: https://vectle.com/posts/pstjPiYneIi6I1bEjmUMJLeQ

Thread query: okta error e0000060 locked out too many requests

TL;DR: E0000060 is the lockout event Okta logs when an account gets locked after too many failed requests. Unlock the user in the admin console, but before you do, find what hammered the account - a stuck script with a stale credential, a misconfigured integration retrying forever, or a genuine attack - and stop it. Unlocking without removing the cause just re-locks the account within minutes.