The code is a response, not a fixture
Most people never see it. The verification code field on our sign-in page is hidden until something has gone wrong from your network address: three failed attempts within the hour, and the field appears with a small distorted image beside it. Get it right first time, every time, and you will use this product for years without knowing the field exists.
That design is deliberate, and it is the opposite of the older habit of showing a puzzle to everybody on every attempt. A permanent challenge taxes the thousands of people who are simply signing in, in order to inconvenience the few who are guessing. A conditional one is free until the moment there is a reason for it.
The trade is that when it does appear, it appears without explanation, at exactly the moment somebody is already frustrated by having mistyped their password twice. This guide is the explanation.
Two limits, counted in different dimensions
There are actually two independent protections on the sign-in path, and they count different things. Knowing which one you have hit tells you what to do about it.
The first counts failures from a network address. Three within the window and the code field appears. It does not care which account was being attempted — three failures against three different accounts trip it exactly as three against one would.
The second counts failures against an identifier: ten within a fixed fifteen-minute window, after which that email address or site ID is refused for the remainder of the window regardless of which address the attempt comes from. This one exists because address-based throttling alone is defeated by spreading guesses across proxies, which is inexpensive to do.
Both refuse with the same wording, and that sameness is intentional. The identifier limit applies identically to accounts that exist and accounts that do not, so the response cannot be used to work out which email addresses have accounts here. A limiter that only engaged for real accounts would be a slower but perfectly serviceable way of enumerating our customers.
Sustained failures also raise a decaying score for your address, and past a threshold the sign-in is refused for a while even with a correct code. That score halves roughly every ten minutes, so it falls back below the line on its own; there is no way to clear it faster, and waiting is genuinely the remedy.
Which address you are counted as
Almost everything above depends on one question: what address are you? Get that wrong and the whole mechanism either punishes the innocent or protects nobody.
The address used is the connection our servers actually see. Headers that claim to carry the real client address are honoured only when the connection reaching us comes from a proxy we have specifically configured, and the header naming a specific network's client address is trusted only from that network's own edge. Where a forwarded-for chain is present, it is walked from the trusted edge inward, skipping known proxy hops, and the first address that is not one of ours is taken.
The reason for that care is that these headers are attacker-supplied by default. A bot that can invent its own address gets a fresh counter on every request and never reaches three. Reading the chain from the wrong end is the same bug with extra steps. When the configuration is missing or ambiguous, the code deliberately falls back to the connection it can see — which may over-count a legitimate proxy's users, but never under-counts an attacker into invisibility.
The practical consequence for you: an office behind one shared connection is one address. If three people mistype passwords on a Monday morning, the fourth gets a code field they did nothing to earn. The same is true of a VPN concentrator, a school or a coworking space. It is not a fault; it is the price of counting something an attacker cannot forge.
What clears it, and what merely expires
A successful sign-in clears the counter for your address immediately. That is the fast path, and it is why the field usually disappears the moment somebody in the office gets their password right.
Failing that, the record expires an hour after the first failure that created it — not an hour after the most recent one. The window does not slide, so continuing to try does not extend your penalty, and the counter does not creep upward indefinitely across a long afternoon. An hour after the first mistake, the record is gone and the count is back to zero.
One asymmetry is worth knowing. Signup and password recovery raise the same counter but do not clear it on success, because neither has a moment that proves who you are the way a correct password does. So a code field triggered while recovering a password stays for the rest of the hour even after the recovery email is on its way. That is a mild inconvenience by design rather than an oversight.
Because the counter is shared across sign-in, signup and recovery, the fastest genuine remedy is often the least obvious one: sign in successfully once from that address, and everything else on it goes quiet too.
The image is drawn on our own servers each time it is requested: the code in a plain bold face on white, with a couple of straight lines drawn across it, and no external service involved. The endpoint that serves it is marked to keep search engines out of it, and it returns an image and nothing else.
The refresh button asks for a new one, and the code really does change — the request is recorded, and that recording is part of what the next code is derived from. If the image is hard to read, refreshing is the correct move rather than a superstition.
Two honest limitations. The code is issued per address, so everyone sharing your connection is shown the same one at the same time. And a rendered code with a couple of interference lines is a modest obstacle to automated reading, not a strong one. This is not the load-bearing wall in the account's security — the account limiter, the throttling and the password itself are. It is a speed bump placed exactly where volume attacks would otherwise be free.
If your team runs into the field regularly, the durable fixes are ordinary ones: a password manager so nobody is typing from memory, and, where your plan includes it, single sign-on so the console is entered through your identity provider rather than through a password form at all.
Where else the same counter appears
The same store is read and written by the sign-in page, the signup page, the password-recovery page and the endpoint that draws the image. That is a design decision with a sharp edge, recorded in the code as a warning to whoever touches it next: every page that reads or writes this counter must resolve the address the same way. If the page issuing a code and the page checking it disagree about who you are, they key different buckets, and every code fails for every real person while remaining trivially bypassable.
That coupling also explains a behaviour that looks like a bug and is not. Trip the counter on the signup form, then go to sign in, and you will be asked for a code there too. One address, one counter, four surfaces.
The signup path has extra protections of its own beyond this counter, since an unprotected signup form is the most attractive surface on any product of this kind. Those are separate mechanisms with their own windows, and they are the reason a scripted flood of new accounts does not simply take the three-failure route.
What to tell your team
Four sentences cover almost every occurrence:
- The field appearing is not an account problem. It means this network address has recent failed attempts — possibly not yours.
- Type the code shown, or refresh it if it is unclear. A wrong code is refused before the password is even looked at.
- One successful sign-in clears it for everybody on that connection.
- If you are told to wait, waiting is the remedy. There is no support action that unlocks it faster, and the wait is measured in minutes.
For administrators there is one thing worth doing proactively: make sure the people who administer the account are not the ones typing passwords from memory into a form on a Monday morning. Almost every occurrence of this field in a healthy account traces back to that. Chat security basics for admins covers the rest of the account hygiene this sits inside.