agent load-tested the login endpoint and locked out the shared test accounts with failed-attempt throttling

TL;DR

Hammering one shared account with N virtual users trips failed-attempt throttling almost instantly and locks out everyone using that account. Restore access, then stop logging in per virtual user: authenticate once and reuse the session for the measured requests, or provision dedicated per-run accounts. Reserve direct login load testing for a deliberate, isolated run.

The query

agent load-tested the login endpoint and locked out the shared test accounts with failed-attempt throttling

Steps

1. Unlock the accounts and confirm the team is unblocked

Reset the lockouts through the admin console or support flow, and confirm the team can sign in again.

Expected: shared accounts working, team confirmed unblocked.

2. Provision dedicated load-test accounts

Create a pool of test-only accounts, one per virtual user or a generous pool shared across them. These accounts must belong to the test run, never to the team.

Expected: a set of accounts whose lockout affects nobody but the test.

3. Take login out of the hot loop

For most load tests the login endpoint is not the thing under test. Authenticate once per virtual user at ramp-up, then reuse the issued session for the requests you are actually measuring.

Expected: login called O(users) times, not O(requests) times; throttling never engages.

4. If login itself must be tested, isolate it

When the login path is genuinely under test, run it as a separate deliberate test: dedicated accounts, throttling exempted for those accounts in the test environment only, and a rate the throttler is configured to expect.

Expected: login throughput measured without collateral lockouts, throttling behavior tested on its own terms.

5. Add an account-safety check to the test workflow

Before any auth-touching test, the agent must verify: the accounts under test are dedicated (not shared), throttling policy for the environment is known, and the planned rate stays under the lockout threshold or an exemption is in place.

Expected: the check blocks any future run that would target shared accounts.

Use this when

• A load test locked shared or team test accounts
• Login throttling engaged during a benchmark
• The agent reused one account across all virtual users
• You need to separate login testing from application load testing

Not for this skill when

• The lockout came from a real attack (security incident, different playbook)
• Throttling behavior itself is the system under test and the lockout was the expected result
• Accounts are locked for billing or admin reasons unrelated to load
• The test never touches authentication at all

Variant phrasings

load test locked test accounts

Same fix: dedicated accounts, login out of the hot loop, exemptions for deliberate login tests.

login throttling during benchmark

Throttling is per-account. Spread the load across accounts or bypass login in the loop.

shared account locked by stress test

Shared accounts and load tests do not mix. The account plan is part of the test plan.

Why it happens

Throttling is per-account, but load generators default to per-virtual-user credentials, and the easiest credential to grab is the shared team account. N virtual users times one account reads to the throttler as a brute-force attack, which is exactly what throttling is for. The agent tested throughput and accidentally tested the abuse defense, with the team's accounts as the casualty.

Edge cases

• Session expiry mid-soak: long runs outlive session lifetimes. Build token refresh into the harness or the measured traffic silently becomes 401s.
• SSO-backed test accounts: the identity provider may throttle independently of your app. Coordinate exemptions at both layers.
• CAPTCHA or bot checks on login: these break automated login testing entirely. That is a sign to test behind the login, not through it.
• Testing the throttler deliberately: do it against dedicated accounts at a known threshold, and label the run as abuse-defense testing so nobody misreads the lockouts as an incident.

Provenance

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