I create a website where a user needs to to fill in a form. After that the form starts to call an API with this input.

Unfortunately the API response is very slow and sometimes user has to wait about one minute.

I have read from UX Movement that if the user needs to wait so long it is better to use a progress bar instead of a spinner.

I cannot predict how long the api call will last. Therefore, an accurate display of the progress is difficult.

Do you have any experience or ideas how to handle this?

  • 3
    While waiting for the operation to finish, can user perform any other actions in the system? Or is the interface blocked until all the API requests are done? Commented Mar 22, 2017 at 9:51
  • 110
    Every time I come across something like that I'm always worried my browser will loose connection midway through the process and I'll have to start over. Please implement a way of accessing the operation's results later on (through a link in the user's profile, e-mail notification, etc) even if the "processing" page is closed. Commented Mar 22, 2017 at 10:09
  • 6
    Why exactly can't you estimate how long call takes? If it is a complex action, can API itself return you estimates for each stage so you can give at least some meaningful numbers? Commented Mar 22, 2017 at 14:32
  • 4
    @TobiasKienzler If a developer is relying on a progress bar to help debug their application then they're doing it wrong. It may indicate that the application has hung, but nothing more. In this instance, the sentence I cannot predict how long the api call will last should indicate the definitive answer. Commented Mar 23, 2017 at 12:22
  • 8
    It doesn't sound like the OP was asking for a lot of alternative ways of designing the web page (such as rewriting the entire user experience or processing the submission and sending an email when it's done, etc). It looks like he/she was simply asking if a spinner is better than a progress bar. My personal pet peeve on StackExchange is when someone asks a specific question and a bunch of people reply by telling them to do something completely different or use a totally different technology. Stick to the original question unless the original post asks for a better/different solution. The assum Commented Mar 23, 2017 at 16:28

15 Answers 15


There is a difference between a spinner and a progress indicator:

  • a spinner only communicates the wait,

  • a progress indicator (be it a progress bar or any other form going from 0 to 100%) communicates wait and progress.

To communicate progress, exactness it is necessary. This is why those installation progress bars, stopping at 99% are so frustrating. Therefore, showing a progress bar in a situation when it is not possible to say when the process will finish is a bad idea.

To make the waiting less painful for the User, though, and give them some information about the process in the background, you can apply some or both of the following:

  • make the process run in background of User actions - to do this, you can show a progress indicator somewhere in, for example, the top right corner of the screen while not stopping the user from the other actions that they can perform in the system.

  • communicate the approximate wait - this is just saying something like "This usually takes up to a minute." - it will still give your User some understanding about how long they need to wait for it to finish.

  • if the action results in displaying some items to the user, you can present placeholders that will fill with data once the operation finishes. This is something that you can see, for example, when visiting LinkedIn.


  • another thing you could consider, would be combining some of these – for example by showing a system busy indicator (e.g. spinner) supported by an information that "It usually takes up to 30 seconds." and then, if the operation takes longer, allowing User to choose between waiting longer or getting back to the results list after the operation has finished. Similar pattern is used e.g. in Chrome when a tab is not responding for some time, as far as I remember.
  • 1
    I think this is very true if you only can assure that the process concludes within some short time. Should it be guaranteed 3-5 seconds, I would not hesitate displaying 0-40% progress within the first two secs, then topping it up after the process is done. But one minute - well, that is a lot of time to get frustrated... Commented Mar 22, 2017 at 20:23
  • 23
    if the wait is inexact but known to sometimes be quite long, what about also displaying which phase of the process you're on? like, display "Connecting to server...", "Accessing profile...", "Making changes...", "Closing connection...". i will admit i don't have any UX training, but that usually makes me feel more comfortable when i've been staring at nothing but a spinner for 30+ seconds. Commented Mar 22, 2017 at 21:14
  • 22
    @DominikOslizlo but even if he can't comprehend what they mean exactly, when he sees the text change, that tells him that progress is being made, and that the program is not infinitely stuck. I think that's the main value these lines have over a simple spinner, as long as it doesn't stay stuck on one particular line for too long (in that case one might want to split it up into its constituent steps).
    – JoL
    Commented Mar 22, 2017 at 22:01
  • 1
    @jlmg – I think you may be right about a lot of situations, but for another lot of them the actual, verbose status does not matter until the User feels there is a problem – only then they refer to it. As an example, I never had a need to analyse what happens behind all these dial-up sounds back then: youtube.com/watch?v=gsNaR6FRuO0 The only thing I was waiting for that really did matter was that sweet sound of silence at the very end of them. Commented Mar 22, 2017 at 22:54
  • 1
    Usually, progress bars are a total fraud. Commented Mar 23, 2017 at 8:35

For a wait as long as that, I would be reluctant to ask the user to wait at all.

Consider showing them a result such as "Thank you, your form submission has been accepted and is being processed, you will be notified by [method of notification] once processing is complete. This is usually within [x] minutes"

Now they can leave the form, or page, or whatever they are on, and get on with whatever they want to do. When the processing is complete, send them a notification (email, SMS, IM, whatever you feel is appropriate) and provide them a link to click and resume where they left off.

This way they are not wasting their valuable time sitting looking at a page wondering how long it is going to take. They won't feel like there is anything they can do to speed it up (why users think submitting again or refreshing will somehow help will always be beyond me!) so they will be more likely to simply accept it and move on with another task until the notification appears.

If the users are already identified by this point, also consider a message at the start of the form, if a user revisits the page while their submission is still being processed, informing them of the status (even if it is rather vague, as I assume since you cannot provide an accurate progress bar, you don't have much detail on the status)

  • 6
    Users resubmit on interfaces that do not adaquately communicate progress. Has it started? Has it frozen? Did I remember to press the button? Did it register my click?
    – Gusdor
    Commented Mar 24, 2017 at 12:37
  • @AnoE my comment was to address this note: "why users think submitting again or refreshing will somehow help will always be beyond me!"
    – Gusdor
    Commented Mar 24, 2017 at 13:18
  • 6
    @Gusdor: Because historically it actually worked a lot of the time. You had awful IIS-based servers where requests would go to NUL: with no indication to the client, and resubmitting a few times would get it to go through. That kind of thing still happens on some poorly implemented sites. Commented Mar 24, 2017 at 16:20
  • 2
    And +1, this is the best answer. If a task is going to take a nontrivial (more than ordinary page load) amount of time, you need to present it to the user as a background task where they'll receive notification when it finishes, not as a progress indicator of any sort. Even if the latter weren't atrociously annoying to desktop users, it's a huge problem for mobile users who don't know whether letting the screen turn off or switching away from the browser might interrupt/cancel the operation. Commented Mar 24, 2017 at 16:23
  • 5
    Many times when a page takes more than a couple seconds to load, I click the Stop X then the Refresh and it usually reloads instantly. That is why users resubmit. Because, it works! TCP/IP has an exponential backoff which is part of the reason that this can happen. I know that, so I even have a technical and correct justification for reloading a stuck page load. For anything except a payment button, I figure that there is no harm in resubmitting, for the same reasons. Even payment systems will screen out duplicate payments. No harm, all benefit. Like the Close Door button in the elevator!
    – user67695
    Commented Mar 24, 2017 at 16:36

If the progress takes longer than a few seconds, you should think about the user-experience. You cannot expect the user to stare at a progress bar for one minute - the user will do something else in the time, while a long progress operation finishes in the background.

If you show a progress bar it has to be accurate (so waiting time can be inferred by the user) - if you cannot provide accurate feedback of progress better use a spinner and a text with the expected loading time.

Most importantly: Provide an option for the user to re-engage once the operation is complete. This can be a desktop notification, a sound or a tab-bar flashing/change of favicon and tab-title in the browser to signal completion.

Your request is being processed, usually takes about 2 minutes.

Please do not close this window.

You will be informed via notification when the progress completes.
  • 43
    Do not randomly start playing sounds in a Web application. Commented Mar 23, 2017 at 6:38
  • 2
    You can provide checkboxes, where the user can choose if he wants sound. As I wrote: the notification type depends heavily on context. A private smartphone user will have different requirements than a professional user using an intranet application for work
    – Falco
    Commented Mar 23, 2017 at 7:24
  • 4
    Sounds are fine as long as it's a per-user opt-in option and not the default.
    – barbecue
    Commented Mar 23, 2017 at 17:58
  • 1
    Updating Microsoft Windows. Do not turn off your computer.
    – user67695
    Commented Mar 24, 2017 at 16:38
  • 1
    @nocomprende Oh no; it's closed my unsaved work again? Why does the timer still tick down when the window hasn't got focus?! (Perhaps they should've asked here...)
    – wizzwizz4
    Commented Mar 24, 2017 at 19:59

Besides all mentioned above, I would suggest adding intermediary updates, e.g.

  • Loading...
  • Still loading...
  • Yet still loading...

If the text changes it'll give a clue to the user that process is not hanged.

Depending on your app personality messages can be humorous or formal.


  • Why not make a cup of tea?...
  • Or coffee?...
  • Or even hot chocolate?...

One thing to be aware of: in case of error there is no place for humor.


  • Searching for a free database connection...
  • Contacting database...
  • Submitting data to database...
  • ...

An example of formal: Photoshop loading window (reading brushes) enter image description here

Edited with suggestions of Klaws and John U

  • 1
    Best example: Save disk format routine from Cannon Fodder. Includes "Why not make a cup of tea?"... "Or coffee?" ... "Or even hot chocolate?"...
    – John U
    Commented Mar 23, 2017 at 11:48
  • 2
    +1 to "give a clue to the user that process is not hanged" Commented Mar 23, 2017 at 18:02
  • 3
    @ssdecontrol agree...as long as the change in text REALLY indicates that the process is not hanged. e.g. if it's just a Javascript changing the text every 15 seconds until the server responds, the server can be bombed and all humanity be extinguised that the text will keep changing. I always fear being in one of those (poorly implemented) situations.
    – xDaizu
    Commented Mar 24, 2017 at 11:34
  • 2
    I smell a great Sci-Fi short story. Off to worldbuilding.stackexchange.com I go Commented Mar 24, 2017 at 15:35
  • 1
    @can-ned_food Personally I don't get why you would be happy when the page is not found, but it's like a strange convention. In forms though you probably shouldn't be joking when the user waited for a couple of minutes and something got wrong because well... it's frustrating and must be communicated clearly
    – Runnick
    Commented Mar 25, 2017 at 10:17

If you can't make the wait informative, at least make it entertaining.

For example, on a certain web site Bill Shatner makes some funny faces and hand gestures while a notoriously slow system is interrogated. You may not be the best person to build that humor, but perhaps you can consult with your business image or marketing team and ask them to suggest "while you wait" content for your user.

Don't be tempted to put distracting information in this gap. The primary content should be informative or humorous. Informative information might be a video tour of the system just provisioned. Humorous might be a carousel of employee's dogs. Marketing people might be tempted to put ads for related products: don't let them, or at least argue such ads should be small.


Assuming one minute is as fast as your process is going to get, and this is a critical component, I would consider coordinating with Engineering to modify the approach so it no longer takes place in a long-running API call.

Here's a high-level approach to a user experience similar to what you might see on something like Dominos Pizza's order tracker:

  1. Modify the current API so that it adds a message to a queue, then responds immediately.
  2. The UX immediately displays a progress bar at 0%, then waits for notifications.
  3. A background worker process picks up the message and begins processing.
  4. Modify the processor logic by adding status updates at various milestones.
  5. Send these status updates back to the user through push notifications, updating the progress bar.
  6. When the UI receives the last update, confirming that the process is complete, move the user along to their next view.

Which bug report would you prefer reading:

  • The spinner just keeps spinning.
  • Progress is temporarily stuck at 78 %.
  • The app takes very long to perform the "Rectifying delta wave" stage, ten times longer than the estimate of the one minute given.

Yes, the latter may not be something the user understands, but nonetheless this is the information you as the developer will need in order to improve performance or fix bugs. So unless the action should finish quicker than the initialization routine for a progress indicator, please do provide sufficient information for the user to known whether it's worth their time to wait or to multi-task somewhere else for a while. And don't entirely block the device unless you absolutely have to.

  • 2
    I find ten minutes of delta waves very refreshing. There's a nap for that.
    – user67695
    Commented Mar 24, 2017 at 21:35
  • @nocomprende :D Bug report: "Updating the app triggers REM sleep, please update more often so I can sleep better" Commented Mar 25, 2017 at 20:20

The most important thing is to explicitly inform users that the loading can take some time (around a minute) and show progress indicator. In my opinion, it doesn't matter that much whether it would be a spinner or progress bar as long as is showing that it's working on the task.

There is a problem with the progress bar when you cannot offer a accurate representation in long periods of loading. Imagine that the progress bar stuck on 40% for considerable time. Users will start thinking that the site has stopped loading while in reality it is not. In this case users are likely to abandon the process and you definitely want to avoid that.

Another good idea is to show animation or a picture while they wait. This way their attention will be kept at the page. Of course this depends on your type of application.

  • 1
    If you’re trying to hold their attention with filler content for more than a few seconds, you’re wasting their time. Let them tab away and do something else instead.
    – PLL
    Commented Mar 24, 2017 at 8:17
  • @PLL This filler content does not stop them from switching tabs. It's purpose is to try to avoid that. But of course in some contexts this would be appropriate while in others not. Just an idea. Commented Mar 24, 2017 at 9:34

There are many issues with a long wait, mainly:

  • how can the user differentiate between a situation in which the website failed them compared to the website just being slow?
  • what are the consequences, for the user, of losing their connection? having their browser crash?
  • what are the consequences, for the user, of re-submitting the form?

However, attempting to address these issues with text can surprisingly backfire. Whenever I see a website that makes me wait with a text the likes of:

Do NOT refresh this page, your payment could be processed twice!

I get really worried, and generally avoid returning to the website:

How confident should I be in a website's payment handling if they can accidentally charge a customer twice? Well, not confident at all!

The key issue is that this is NOT just about making a user wait, it's about assuring the user that:

  • their request is being addressed,
  • their request will not be lost,
  • they can at any time resume the handling of their request.

If your user is logged in, you can simply store the request in their profile inside the website database. If the user is not logged in, you can generate a globally unique ID and store it in a cookie or local storage on the user's browser.

In either case, from the UI point of view you need to:

  • show to the user that their request was acknowledged and registered (even if not processed yet),
  • allow the user to check on their latest requests, at the very least those that were completed since the previous time they connected, so they can resume their task.

Both steps can be accomplished by having a "history"/"recent requests" box visible to the user, and adding their current request to the box to acknowledge it's been made. A little icon that differentiates the "step" at which the request (draft, submitted, in progress, completed/cancelled) is a cherry on top.

This will go a long way to assuage a user's fear or insecurities from the wait itself.

And now, and only then, do we address how to best make the user wait.

The first question is:

Is the user actively waiting, or can the user be notified asynchronously?

If the latter, then just tell the user they will be notified. I'll assume that they wish to proceed immediately.

In this case, as mentioned, I encourage you to display a progress bar rather than a spinning wheel, to convey the idea that progress is made:

  • the duration of the progress bar should be a rough estimate of your 90th/95th percentile for the API call; it's much better to complete early than get stuck at 99% (keyword: stuck),
  • if possible, steps should be displayed atop the progress bar ("Step 1/5: X", "Step 2/5: Y", ...),
  • do not wing it, only display steps if you can check with the API at which step the processing is.

Whether you allow the user to work on another request in the mean-time or not is up to you and depends on the usage.

Also, displaying ads and gags while the user waits may not necessarily be taken positively; angry impatient users have little humour and little patience for your attempts at making money.


I recommend a status graphic of either penguins or lemmings walking of a cliff and piling up at the bottom.

This will give the user an idea of how much time has passed (number of dead penguins) and how much time is left (space left in the pit).

The user will know that the process has failed/hanged, when there is no more penguins, or no space for them to move forward.

This is superior to a percentage of status bar as the user does not know how many penguins will fit in the pit. (Much like guessing jelly bean count in a jar) The user will thus have no expectations for you to fail to achieve.

Unlike a spinning wheel, etc, this gives feed back and does not make the user think that nothing is happening. People believe that long spinners are a sign of lag. This belief comes from decades of Microsoft Hour-Glass and Apple infinite color wheel experience.

Also this visual will give your user a much needed brake from the boredom of day to day app/web usage.


I have read that if the user needs to wait so long it is better to use a progress bar instead of a spinner

Yes, but that's the effect, not the reason:

Progress bar is for when you can measure how the process is progressing (!). Something among the lines of "when X happens it usually means we're about halfway done so set the progress to 50%".

Spinner is for when you don't know how long will the process take. You don't know if you're almost done or just beginning so you keep it spinning and "it'll be done when it's done".

The "don't know" often comes from "don't care, because it's so short anyway", and that's how the article author came to his/her conclusion. But it's clear that the author made hidden (and false!) assumption that all operations (and especially the long ones) are measurable. Bottom line: there is a connotation "short = spinner, long = progress" but it's merely a coincidental one, not some fundamental rule.

I cannot predict how long the api call will last. Therefore, an accurate display of the progress is difficult.

That's why we've invented spinners in the first place!

There is also a thing called "indeterminate progressbar". But it's doesn't carry meaning any different than spinner. It's purpose is to be visually coherent with regular progressbars, so you can use same dialogs, graphic and layouts with both types of operations.

The "redesign your flow" was stated already, no need of repeating that, because the best spinner/progress bar is the one that's never needed.

  • 1
    The problem is that in the majority of cases where people encounter a spinner that keeps going for more than a minute, it will never finish because some request has timed out but the application didn't handle that case. Users have learned that if a spinner persists for longer, it means they have to abandon and restart the workflow. Whatever spinners were invented for, they are effectively incorrect to use for anything that takes longer than a few seconds. Commented Mar 24, 2017 at 9:30
  • @MichaelBorgwardt That's true, but it's not the point of my answer. A stuck progressbar evokes exactly same reaction: "something hung up, let's try again". A badly calibrated progressbar only adds insult to the injury.
    – Agent_L
    Commented Mar 24, 2017 at 16:43

Keep the user informed

If you know the approximate or maximum times it'll take, those can be used as progress markers as well. Some kind of animation or divertesment during the wait can make it slightly less painful. If you can get "partial" steps informing the user when those happen can also break the monotony.

Even if you're not getting any info back from the API, let the user know every 15 seconds or so that your service hasn't broken and is still waiting is good.

Better yet, if after the expected maximum duration has elapsed you let the user know of any alternative method of submission (retrieval?) of the info that will help too...

It's been two minutes, something has probably gone wrong, this usually doesn't take quite that long! contact name@email


The goal here is to keep the user informed at all times without introducing more information to them than necessary. A user whose request is processed fast needn't know about average wait times, and a user who has been waiting for 5 minutes does not need to know that the process usually takes a minute.

Here is one suggestion which would achieve this - have a progress bar capped at 1 minutes with text below it. Initially the text would convey "working on it", then after about 10-15 seconds have elapsed you update it to "this usually takes not more than a minute", and after a minute has elapsed and the progress bar is full, you could replace the message by a reason on why it might be taking long and what user can do about it. Something like "We use the x API, and they seem to be responding slowly at the moment." followed by an advice on what they could do like "We'll send you a notification once this completes", or "Please try again later" might be good.

Again, you can still customize your message as time elapses even after a minute. If you know that 95% of user requests are satisfied within 1 minute, 30 seconds then saying "We use the x API, and they seem to be responding slowly at the moment. Hang on for a while" and changing "Hang on for a while" to some other message after 1 minute, 30 seconds.


All this talk about different presentation styles is beside your core concern here:
Your users are supplying information on a website form which contacts the remote server.

If there is a long wait, then it seems to me that your largest concern here is that the user will think the connection has hung. So it will take an indeterminate amount of time, probably 1 minute but anywhere from 30 seconds to 5 minutes depending on server load? Have a message saying so, sure.
That message should have a small animated component — a simple Cylon eye will be adequate — so as to initially catch attention: the user needs to know that this message is not simply a static blurb which can be perused whenever.

The major concern here is to keep the user informed that the connection to the server hasn't been lost, or that the server-side script hasn't frozen or crashed. And, to do so in a way which doesn't require them to begin pulling up diagnostics or whatever.
You can't cheat this, because if your users will use the system more than once, they need to know that the information provided to them is reliable.
You should probably use the same methods by which you are keeping the HTTPS session open — i.e. a client-side script which pings so as to prevent time–out.

A simple message with a blinking indicator, saying something to the effect of

Status: processing . . .

would probably be best for your situation. There you could show various other messages, also:

Status: connection lost!

But, it needs one more thing: How do your users know whether the client-side script is responsive? Depends on what you are using, but I recommend that you write something which shows the local time. That way, if it hangs, they can compare that clock to another.
Don't rely on being quirky with the mouse cursor or the like, because some users will block scripts from being able to do so.


Have the progress bar start out fast, then get slower and slower. Use a formula such as 100-100/([time in seconds]/30+1) so it will take an infinitely long for the progress bar to go to 100% with time=29 being 50%, time=60 being 67%, time=300 being 91%

  • What's the benefit to this solution? This will make the user think the system is getting slower and slower. So I, for one, would be temped to quit. Commented Mar 27, 2017 at 19:57
  • Reminds me of Achilles and the Tortoise, and would be a frustrating model for a progress bar. Commented Mar 27, 2017 at 21:05
  • It communicates that the system is getting bogged down, but is still making progress. Commented Mar 31, 2017 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.