Usually feels like
Minutes
You stay at the keyboard and it finishes there.
A gate is doing work for every visitor at once, which puts it above the seconds band, but it is built to end where you are sitting.
The wait, in plain words
The address resolved, the circuit held, and what came back is a bare page telling you to wait while something is checked. There is no form to fill in, no button that does anything, often nothing to read past one line. The tab sits there with the market behind it.
A gate screen is a layer placed in front of the shop by whoever runs it. Every request that arrives has to get past that layer before the market is asked to do any work at all. When the layer is busy it holds you. When it is not, you pass through fast enough that you never learn it was there.
This belongs in the minutes band rather than the seconds band because the gate is doing work per visitor and is often doing it for a crowd. It usually ends where you are sitting. If it does not, the problem has changed shape, and a changed shape is a different card.
Underneath, while nothing moves
A service reached this way cannot see who is knocking. There is no network address to count against, no country to filter, no history to look up. Everything arrives through the same kind of tunnel, and an automated client looks exactly like a person from the outside. That single fact shapes every gate you will meet.
So gates weigh what they can see. How fast requests arrive down one circuit. Whether the client will do a small piece of work that costs a browser very little and costs a script farm a great deal. Whether it holds a token issued a moment ago. Whether it will render a picture and answer a question about it, which is the captcha sitting at the front of many of them.
Some gates are not tests at all. They are queues. When more people arrive than the shop can serve, the front layer accepts everyone and releases a trickle. That is unpleasant to sit in, and it is cheaper than letting the market fall over behind it. From your side a queue and a test look identical, because both hand you a page that says wait.
The unhelpfulness is deliberate. A progress bar tells an automated client how close it is and lets whoever wrote it tune the attempt until it passes. A gate that says the same thing at the start and at the end gives away nothing. The cost of that design is paid by you, sitting in front of a screen with no way to tell a slow pass from a stuck one.
- What a gate can see
- The rate of arrivals down one circuit, and whether the client behaves the way a browser behaves.
- What it cannot see
- Who you are, where you are, or whether you were here earlier on a different path.
- Why it holds everyone
- Shedding load at the door is cheaper than letting the shop fall over behind the door.
- Why it says so little
- Anything that reports progress to you also reports progress to whatever is being kept out.
Behaving, and not behaving
A gate that is slow and a gate that will not open are different animals, and they are told apart by change rather than by time.
A gate working through you
Coming back to it after a long sit gives you a slightly different page. A new challenge, a new token, a different line of text. Something on the far side is still generating things for you.
The tab holds a live connection rather than sitting on a finished one, and left alone it eventually flips to the market by itself, without you having touched anything.
A gate that is not going to open
The screen is identical every time you look at it, including the parts that ought to be generated fresh, and no amount of sitting changes it.
Or it does advance, drops you at the market, and immediately throws you back to the same screen, in a loop that will repeat for as long as you keep feeding it.
The loop is the one worth recognising early. It usually means something about the request keeps failing the check rather than the check being slow: a browser configuration the gate cannot work with, a token that will not stick, or an address that answers without being willing to serve you. Failing the same test over and over is its own wait, and that wait does not belong in this band.
The other honest outcome is that the gate is fine and the shop behind it is not. A door can be perfectly attentive to a building that is closed. Nothing written on the door will say so.
Safe to do meanwhile
The gate is not asking you for anything, so there is nothing to do to it. Whatever is useful during this wait is useful somewhere else.
- Leave the tab aloneA gate you are not touching is a gate that gets to finish.
- Read the address string againThe wait in front of this one is the last that you can still get wrong by hand.
- Note exactly what the screen saysThe wording is the only evidence you will have if this turns into a longer wait.
- Decide now what you will do if it loopsA plan made while waiting beats a decision made while annoyed.
What makes it longer
Almost everything that lengthens this wait is something done to it from your side.
- Reloading. Each reload throws away whatever the gate had already done for you and puts a fresh arrival at the back of the same queue.
- Opening the same address in several tabs. To a layer counting arrivals down one path, that is exactly the pattern it exists to slow down.
- Asking for a new circuit in the middle of a check, which loses the token the gate had issued you.
- Arriving when everyone else arrives, which is when a front layer stops testing and starts queueing.
- A browser set up in a way the check cannot complete, so it never passes and is never told why.
What this card is not. This is a description of how doors of this kind work, not of any one door, and nothing here can tell you which screen a given address puts in front of you.