Progress bars stall at 70%—the reward lands at 100

Why does a progress bar that stalls at 70 percent feel like a personal insult? We know the file is still downloading, the form is still submitting, the build is still compiling. And yet something in us reads that frozen bar as a small betrayal. What's actually happening there is one of the more useful things a business can understand about the people using its website.

The bar is a promise, and the last 30 percent is where trust lives

A progress bar is a strange piece of interface design when you think about it. It doesn't do any work. It just tells you that work is happening somewhere else. Its entire job is to manage a feeling, and it does that job by making a prediction: this will end, and here's roughly when.

Behavioural researchers call the gap between where you are and where you want to be the goal gradient. The closer you get to a finish line, the harder you push. In one of the classic studies on this, researchers handed people loyalty cards — some needed ten stamps for a free coffee, others needed twelve but were given two stamps to start. Both groups needed ten more purchases. The second group finished faster. Same effort required, but the card that felt already started got people to the finish line sooner.

That's the whole trick of a progress bar. It makes the goal feel underway before you've done anything. Which is also why a bar that stalls at 70 percent is worse than no bar at all. It has already made the promise. Then it breaks it.

What a stall does to a user

Daniel Kahneman's work on loss aversion gives us the uncomfortable part. Losses hurt roughly twice as much as equivalent gains feel good. Once a user has been shown a bar creeping toward completion, they've mentally banked the reward. The site is almost done with them. A stall doesn't read as "neutral delay" — it reads as a loss of something they'd already counted on.

Then there's the uncertainty problem. Kahneman and Tversky's research on how people judge probability found that we're far more bothered by ambiguous odds than by bad odds we understand. A bar stuck at 70 percent with no explanation is pure ambiguity. A bar that says "about 40 seconds remaining" and counts down honestly is a known quantity, even if it's slow. Users will forgive slow. They will not forgive being left to guess.

Reward loops explain why we keep watching a bar that isn't moving

Here's the part that gets genuinely interesting, and it's where website development overlaps with behavioural psychology in a way that should make any product team sit up.

The most persistent behaviour in humans and animals alike is maintained by variable reinforcement — rewards that arrive unpredictably. B.F. Skinner demonstrated this decades ago: a pigeon pecking a lever that pays out on an unpredictable schedule will peck far more obsessively than one that gets a reward every single time. Predictable rewards produce calm behaviour. Unpredictable ones produce fixation.

Now think about what a stalling progress bar actually is. It's a variable-ratio machine pointed at your own impatience. The user refreshes. Nothing. They wait. It jumps to 74 percent, then freezes again. Each micro-jump is a small unpredictable reward, and each one buys another thirty seconds of attention. That's not a design feature anyone chose deliberately — but it's the effect, and it's worth naming honestly. A site that accidentally trains its users to tolerate ambiguity is a site that's also training them to distrust it over time.

The difference between a loop and a trap

Reward loops aren't inherently bad. The satisfying thunk of a form submission, the tick that appears when a payment clears, the little animation when a file uploads — these are honest rewards delivered at a predictable moment. They build confidence. The user learns: this site does what it says.

The trap version is when the reward is dangled but never quite lands, or lands at a moment the user can't predict or control. That's the 70 percent stall. The reward is visible, promised, and withheld for reasons the user can't see. Over enough visits, that pattern doesn't create engagement. It creates a low-grade resentment that shows up as abandoned carts, half-finished applications, and people who bounce the moment a page takes an extra second to load.

Decision-making under uncertainty is the actual product problem

Most website performance work gets framed as a technical question: server response times, asset optimisation, caching layers. All of that matters. But the reason it matters is that a slow site forces every visitor into a decision under uncertainty.

Should I wait, or should I go somewhere else? Is this broken, or just slow? Did my payment go through, or did I just pay twice?

These are risk calculations, and people are bad at them under time pressure. Research on decision-making under uncertainty consistently shows that when people can't estimate the odds, they default to the safest option available — which, on the web, is usually leave. Closing the tab is always available, always free, and always resolves the uncertainty immediately. That's the competition every slow-loading page is actually up against. Not the rival business down the road. The back button.

Where competitive play comes in

There's a reason good developers get quietly obsessed with Lighthouse scores and Core Web Vitals, and it isn't only professional pride. It's that performance work has the shape of a competitive game: a measurable target, a scoreboard, a clear ranking, and a sense that someone else is trying to beat your number. That framing is genuinely motivating, and it's not a coincidence that gamified dashboards have crept into development tooling.

The risk is that the scoreboard becomes the point. A site can hit a perfect performance score and still leave users staring at a spinner with no idea what's happening. The metric measures the machine. It doesn't measure the feeling of being stuck at 70 percent with no explanation.

What to actually build instead

If there's a practical takeaway here, it's that the last stretch of any process is where you should spend your design attention, not your least.

Show honest time, not just percentage. A countdown that's roughly right beats a bar that's precisely wrong. If you don't know how long something will take, say so in words: "This usually takes under a minute."

Never let the bar lie backwards. A progress indicator that jumps from 80 percent back to 40 percent does more damage than one that never moves, because it breaks the one thing the bar was for.

Give the user something to do while they wait. A confirmation email that's already on its way, a summary of what they just submitted, a next step they can read. Waiting with information feels shorter than waiting in a void.

Test the slow path deliberately. Most teams test on fast connections with warm caches. Throttle it. Watch what a real person on a real connection in regional Australia actually experiences at 70 percent.

The forward-looking version of this is straightforward. As more business happens through interfaces that take time — uploads, verifications, AI-assisted processes, multi-step applications — the ability to make waiting feel honest becomes a genuine competitive advantage. Not because users are irrational, but because they're predictable. They'll forgive a slow process. They'll remember a process that stalled, promised, and never explained itself.

The reward lands at 100 percent. Everything you do between 70 and there is what decides whether they're still around to collect it.