okta error e0000060 locked out too many requests

Not specified by the original author.

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.

Not specified by the original author.

Fix onboarding agent failing on Okta API rate limits mid provisioning run

TL;DR

When the agent hits Okta's rate limit mid-run, it must back off and resume, not crash or skip users. Catch the 429, honor the retry headers, and checkpoint progress so the run resumes where it stopped. The users are not lost; the run just needs pacing.

The error

Onboarding agent failed
Okta API returned 429 Too Many Requests mid provisioning run. 40 users remaining unprocessed.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent rate limit failed mid provisioning run on okta api"

Fix it

Step 1: Checkpoint progress before anything else

Write the last successfully processed user id to the run state before retrying.

Expected: A rerun resumes from the checkpoint instead of starting over.

Step 2: Honor the rate limit headers

Read the retry-after or rate-limit reset header from the 429 and sleep that long.

Expected: The agent waits the required window instead of hammering.

Step 3: Add backoff with jitter to the Okta client

Wrap Okta calls in retry logic with exponential backoff and jitter.

Expected: Transient 429s clear on retry without failing the run.

Step 4: Slow the steady-state pace

Reduce concurrency or add a small delay between user provisions.

Expected: The run stays under the limit and finishes without 429s.

Step 5: Resume the run from the checkpoint

Restart the agent; it picks up at the first unprocessed user.

Expected: All users provision with no duplicates and no skips.

When this applies

• Provisioning agents hit Okta 429s mid-run
• Bulk onboarding runs die partway through
• You are building agents that call rate-limited APIs

When it doesn't

• The 429 comes from a different API (pace that client instead)
• The run fails on the first call (check credentials, not pacing)
• Okta returns 401 (that is auth, not rate limiting)

Compatibility

Okta Management API rate limits. Any agent framework driving bulk provisioning.

Variant phrasings

agent hit okta rate limit provisioning

Same failure. Checkpointing plus backoff is the standard recovery.

okta 429 bulk user creation agent

Bulk creation is the heaviest pattern. Batch smaller and pace the batches.

provisioning run failed rate limited

Failed runs without checkpoints redo work and create duplicates. Checkpoint first.

Why it happens

Okta rate-limits API clients to protect the service, and bulk provisioning is the fastest way to hit the ceiling. Agents that fire requests as fast as possible trip the limit mid-run. Without checkpoints, the retry starts over and either duplicates work or skips users.

Edge cases

• Different Okta endpoints have different limits; the heaviest call sets your pace
• Parallel agents share the org-wide limit; coordinate or stagger them
• A 429 storm can look like an outage; check the limit headers before escalating

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

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

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

Thread query: onboarding agent rate limit failed mid provisioning run on okta api

TL;DR: When the agent hits Okta's rate limit mid-run, it must back off and resume, not crash or skip users. Catch the 429, honor the retry headers, and checkpoint progress so the run resumes where it stopped. The users are not lost; the run just needs pacing.

Not specified by the original author.

TL;DR

In Okta Admin, go to Directory > People > the user and click Unlock. Then check the sign-in logs for the failure source (wrong password, stale app token, or an actual attack) before telling the user they are clear.

The error

Your account is locked. Please contact your administrator.

Steps

1. In Okta Admin: Directory > People > search the user > click Unlock. Expected: status returns to Active. This is immediate; no sync wait.
2. Check Reports > System Log for the user's recent failures. Expected: you see the failure pattern. Ten password failures from one laptop is a typo loop; failures from many countries is an attack.
3. If the failures come from an old device or mail client, have the user update the saved password there or revoke the stale session. Expected: failures stop. Stale tokens are the top repeat-lockout cause.
4. Review the lockout policy (Security > Authenticators > Password > lockout settings). Expected: lockout threshold and duration match policy. Do not permanently loosen it for one user; use a temporary exception if needed.
5. Tell the user what caused it and the unlock is done. Expected: user signs in. Document the cause in the ticket.

When to use

• Okta shows the account as Locked
• Repeated lockouts with no user action (stale token likely)

When not to use

• The user is AD-mastered and Okta delegates auth: unlock in Active Directory
• The account is deactivated or suspended (different state, different fix)

Compatibility

• Okta Identity Engine; admin rights to Directory > People required

Variants

Locked again within an hour

Almost always a stale credential somewhere (phone mail app, old laptop, script). Find it in the system log by client IP and user agent.

Lockout during a password spray wave

Do not just unlock; check whether the failures are attacker-driven and consider keeping the lock until the wave passes.

Why it happens

Okta counts consecutive failed authentications per the password policy and locks the account to stop guessing. Legitimate users trip it with typos and stale saved passwords; attackers trip it deliberately.

Edge cases

• Service accounts used by scripts: exclude them from the standard lockout policy or the script will keep locking itself.
• Users with password managers that autofill old passwords after a reset: update the vault entry.

Provenance

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

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

Thread query: user locked out of okta after too many attempts

TL;DR: In Okta Admin, go to Directory > People > the user and click Unlock. Then check the sign-in logs for the failure source (wrong password, stale app token, or an actual attack) before telling the user they are clear.