There are two limits, and they count different things
Most sign-in protection counts attempts per client address. That works against someone hammering one machine, and it does very little against someone patient enough to spread the same password guesses across a pool of proxies. Each address stays under the limit while the account underneath takes a beating.
So there is a second dimension. Alongside the address throttle, failures are counted against the identifier being tried, which is to say the email address or site login someone typed into the box. Rotating addresses does not reset that counter, because the address is not what it keys on.
Both limits are live at once. Either can refuse you, and they refuse for different reasons, which is worth remembering when a report of being locked out does not match what you expect.
Ten failures, fifteen minutes, and then it forgets
The identifier limit is ten failed attempts within a fifteen minute window. The eleventh is refused before the password is even considered.
The window is fixed rather than rolling. It starts at the first failure after a clean slate and expires fifteen minutes later regardless of how many attempts follow. Continuing to guess does not extend it. When it expires, the counter is not reduced or aged, it is simply gone, and the next failure starts a fresh window at one.
That design has a consequence people find surprising in the moment: the wait is never longer than the window. Nobody has to be released by an administrator, and there is no escalating penalty for a second offence.
Every sign-in door shares one counter
This is the part most worth knowing, because it explains behaviour that otherwise looks like a bug.
The customer and owner web sign-in, the agent console sign-in, and the mobile endpoint all use the same failure store, keyed on the same identifier. They are not three separate budgets. Ten failures spread across all three still add up to ten.
Sharing is the whole point. Separate counters would mean an attacker who exhausted the limit on one page could simply move to another and start again with a full allowance, which would make the limit decorative. It also means the quieter doors are covered: an endpoint built for a mobile client cannot show anyone a challenge image, so a plain refusal on a shared counter is what protects it.
The practical version for your team: if an agent burns through attempts on the console and then tries the web login, they will find the web login refusing them too. Nothing is broken. It is one counter.
Getting it right wipes the slate
A correct password clears the counter for that identifier immediately.
That is what stops the limit from punishing ordinary human beings. Someone who mistypes an old password six times, remembers the right one, and signs in successfully is not walking around for the next quarter of an hour with four attempts left. Their count is zero again.
The counting itself sits at the single point where the credential check returns, rather than being sprinkled through the individual failure branches. That is a small structural decision with a real benefit: every way of failing is counted, including ways added later by someone who never read this code. There is no failure path that quietly does not count.
It deliberately tells an attacker nothing
A rate limit on sign-in can leak the thing it is protecting. If unknown addresses fail instantly and known ones eventually say you have tried too often, the difference is a way to discover which addresses are real. That is a worse problem than the guessing it was meant to stop.
Here the check runs before the account is looked up, and it applies identically whether the identifier belongs to a real account or to nothing at all. Guessing a hundred addresses against this produces the same behaviour for all of them.
The refusal wording is deliberately uninformative and identical across all three doors: a note that too many sign-in attempts have been made and to wait before trying again. It does not say how many attempts remain, how long the wait is, or whether the account exists. Support teams sometimes ask for a more helpful message here. The vagueness is the feature.
What it is not, and why that is fine
It is not an account lock. Nothing is written to the account record, no flag is set, nobody is notified, and there is nothing for an administrator to unlock. It is a short-lived counter with an expiry attached, and being refused by it leaves no trace on the account at all.
The identifier is not stored as typed either. It is trimmed, lowercased, and hashed, and it is that hash the counter is filed under. Two people typing the same address with different capitalisation share a counter, which is intended, while the counter itself does not sit around holding a readable list of who has been failing to sign in.
It is also, by design, held in the web server's memory rather than in the database. That is the honest limitation: it is a best-effort protection layered on top of the address throttle, not a durable account state machine. It is fast, it costs nothing to check, and it does not survive forever. For its actual job, which is making distributed password guessing expensive rather than free, that is the right trade.
What to tell your team
When someone reports being told they have tried too many times, work through it in this order.
First, it clears itself, so the fix is to wait rather than to escalate. Fifteen minutes is the outside figure. Second, ask whether they had been trying on more than one surface, because console attempts and web attempts are the same budget and people rarely count both. Third, if a person swears they only tried twice, take that seriously: someone else attempting that identifier consumes the same counter, and that is exactly the signal this limit exists to produce. Put the account through a password change rather than dismissing it.
And resist the temptation to raise the ceiling because it occasionally annoys someone. Ten attempts in fifteen minutes is generous for a human who knows their password and stingy for a script that does not.
How MyLiveChat fits
The short version is that failed sign-ins are counted per identifier as well as per address, ten to a fifteen minute window, shared across the web login, the agent console and the mobile endpoint, cleared instantly by a correct password, and behaving identically for accounts that exist and accounts that do not.
Nothing here needs configuring, and there is no setting in your admin area to get wrong. The value of knowing it is in reading the symptom correctly when it appears, and in not treating a legitimate security signal as an inconvenience to be tuned away.
Chat security basics for admins covers the wider account hygiene this sits inside, live chat access control for teams deals with who should have a sign-in at all, and securing the agent workstation covers the machine the sign-in happens on.
The lockout is one of two limits people confuse with each other. The other governs the emails that let you back in, and how long the links in your account emails last explains why a recovery link expires in half an hour while a verification link lasts a week.