Why Does ‘1 Second Remaining’ Take So Long? — How Progress Bars and Time Estimates Work

You have been watching “1 second remaining” for 30 seconds. Just as you expect the task to finish, it changes to “2 minutes remaining.”

File copies, application installations, video exports: progress bars are useful, but sometimes they seem to operate in a different world from the clock.

In fact, a progress bar is not a clock. The percentage describes how much work has been completed; the time estimate predicts how long the remaining work might take; completion means the required operations have succeeded. Separating those three ideas changes how you read a task that will not finish at 99%.

This article explains the general mechanisms using Windows API and UI documentation. It does not reverse-engineer the internal algorithm of a particular File Explorer version. The numerical examples and comparison demo use fictional workloads, not measurements of a PC or network connection.

1. First ask: 100% of what?

Imagine reviewing 100 documents. If 99 are short notes and the last is a long contract, “99 documents finished” can be correct without meaning “99% of the time has elapsed.”

A progress indicator also changes meaning depending on its denominator.

For example, the progress callback used by the Windows CopyFileEx API receives the total file size and bytes transferred. These describe work, not future seconds. ¹

flowchart TB
    accTitle: Progress percentage, time remaining, and completion
    accDescr: The diagram separates a ratio calculated from completed work, a time estimate based on an assumed speed, and completion established by successful results.
    A["Completed and total work"] --> B["Progress percentage"]
    C["Remaining work and predicted speed"] --> D["Estimated time remaining"]
    E["Required operations succeed"] --> F["Overall task complete"]

Figure 1: A ratio, a prediction, and a result are not three names for the same information.

Throughout this article, progress percentage means the fraction of measurable work completed, progress bar means its visual indicator, and estimated time remaining means the predicted duration. Being unable to make a reliable prediction does not erase the progress already measured.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (9 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. How 10 seconds remaining becomes 79 seconds

The simplest estimate uses this equation:

Time remaining ≈ Remaining work ÷ Estimated future processing speed

The difficult part is not division. It is that future speed has not been observed yet. We therefore use past speed to predict it. In a 2004 explanation of copy-time estimates, Microsoft’s Raymond Chen described this difficulty of predicting the future. That article is not a specification of the calculation used in today’s Windows. ²

Consider a fictional 1,000 MiB copy. A MiB is 1,048,576 bytes. Assume that it first runs at a constant 80 MiB/s for 2.5 seconds, then slows to 10 MiB/s for the next second.

The task has advanced during that second. Yet the estimated speed for the remaining work has fallen to one-eighth of its previous value, so the predicted duration increases. This example directly uses the speed from the latest observation interval.

flowchart TB
    accTitle: Why time remaining can rise while work advances
    accDescr: If predicted speed falls enough, its effect outweighs the reduction in remaining work and the calculated time remaining increases.
    A["10 MiB completed in one second"] --> B["Less work remains"]
    C["Predicted speed drops sharply"] --> D["Time remaining can increase"]
    B --> D

Figure 2: An increase in estimated time does not mean the operation has gone backward.

The same applies to “1 second remaining.” An amount that would take one second at the previous speed will take longer if the next operation is slower. Observation intervals and rounding also affect the display. However, a number that never changes should not simply be assumed normal: distinguish processing stages, UI updates, and actual stalls as discussed below.

3. Would averaging make the estimate accurate?

Reflect every brief speed change and the estimate jumps up and down. Use only the average since the start, and an initially fast period can keep the estimate optimistic long after a sustained slowdown.

This follows from how observations are combined. Suppose we give equal weight to a previous speed of 80 and a new speed of 10. The predicted speed becomes 45. It changes less abruptly than an estimate based only on the latest value of 10, but if the speed really stays at 10, it remains optimistic for a while. Smoothness and responsiveness to change are different goals.

flowchart TB
    accTitle: The trade-off when smoothing speed estimates
    accDescr: Giving recent observations more weight makes the estimate responsive but variable, while giving history more weight makes it smoother but slower to adapt.
    A["Speed observations"] --> B["More weight on recent data"]
    A --> C["More weight on history"]
    B --> D["Responsive but variable"]
    C --> E["Smooth but slower to adapt"]

Figure 3: A steady-looking number is not necessarily an accurate prediction.

This is an example for reasoning about estimation, not a description of a particular product. My design recommendation is to avoid forcing a countdown immediately after startup or a stage change. Wait for useful observations, then present an estimate such as “about a minute.” Saying that the estimate is being recalculated can be less misleading than maintaining an unsupported “1 second remaining.”

4. 99 files finished, but only 9.9% of the data

Now consider the unit being counted rather than the speed. There are 100 files: the first 99 are 1 MiB each, and the final file is 901 MiB. The total is 1,000 MiB.

After the first 99 files, the file count gives 99 ÷ 100 = 99%. Data volume gives 99 ÷ 1,000 = 9.9%. Only one file remains, but it contains 90.1% of the data. Both calculations are correct: they measure different things.

flowchart TB
    accTitle: When the last file is large
    accDescr: A large final file after 99 small files makes count-based progress differ sharply from byte-based progress.
    A["99 small files"] --> B["Almost done by file count"]
    C["One large file remains"] --> D["Much of the data remains"]
    B --> E["Different views of one task"]
    D --> E

Figure 4: 99% by file count does not promise that only 1% of the time remains.

Does that make byte counts sufficient? No. Transferring many small files over SMB repeatedly incurs file-creation and request round-trip overhead. The same total byte count need not take the same time as a single large file. ³

Consequently, “500 MiB remaining” can be an accurate measurement while the time required varies with the contents of those 500 MiB. Showing both files and bytes is useful not because one number is wrong, but because each reveals something the other leaves out.

5. “Preparing” can mean discovering the denominator

A percentage needs a total as its denominator. But asking an application to process an entire folder does not necessarily mean it has already enumerated every file inside it.

Suppose the application believes there are 100 items and processes 80, then discovers another 100. Those same 80 completed items now represent 80/200 instead of 80/100. The display drops from 80% to 40%, but completed work has not vanished. Presenting a provisional total as a definite one created the mismatch with the reader’s expectations.

flowchart TB
    accTitle: Displaying progress before the total is known
    accDescr: While targets are being discovered, avoid a definite percentage; once the total is known, combine it with completed work to show a ratio.
    A["Discover the targets"] --> B{"Is the total known?"}
    B -->|"Not yet"| C["Show stage and discovered count"]
    B -->|"Yes"| D["Show a percentage"]

Figure 5: An unknown denominator is different from 0% progress.

Windows provides progress controls for both determinate values and indeterminate activity. ⁴ For this situation, I recommend displaying something like “Finding items: 1,200 discovered,” then showing a percentage once the total is known. The absence of a countdown is not evidence that nothing is happening.

6. “Transfer 100%” and “everything finished” mark different boundaries

6.1 Another operation may remain at the end

For illustration, divide an application’s work into three stages: transfer, verification, and finalizing the result. If the design requires verification after transfer, the overall task is not finished when the transfer ends. This is an example application design, not a claim that every copy or installation follows these stages.

flowchart TB
    accTitle: Transfer completion versus overall completion
    accDescr: This fictional application verifies and finalizes the result after transfer, so transferred bytes alone cannot establish overall success.
    A["Transfer"] --> B["Verify"] --> C["Finalize the result"] --> D["Overall success"]
    A -.-> E["Transfer 100% ends here"]

Figure 6: An explicit scope makes it possible to explain why another stage follows 100%.

Rather than holding an overall bar at 99% with “1 second remaining,” it is more coherent to change the status to “Transfer complete; verifying.” Microsoft’s desktop UI guidance also advises against displaying overall completion before the operation has actually finished. ⁵

6.2 Writes also have more than one boundary

Windows normally uses caching for file writes. Depending on settings and API contracts, writing from the application and committing data to storage involve different boundaries. ⁶ FlushFileBuffers is an API for sending buffered information for a specified file to the device. ⁷

flowchart TB
    accTitle: A conceptual view of buffered writes
    accDescr: With buffering, an application's accepted write and the later storage-side write should not be treated as the same event.
    A["Application writes"] --> B["Held in a buffer"] --> C["Written to storage"]

Figure 7: This is a conceptual diagram of buffered writes, not the completion contract of an individual product.

However, a pause at 99% is not always caused by flushing a cache. Whether the task is verifying, flushing, or waiting for something else must be established from its design or records. Do not infer that it is safe to unplug a USB device or turn off the power merely from a progress number.

7. Has the task stopped, or has only the display stopped?

In a Windows WPF application, the UI thread’s Dispatcher processes UI work. Occupying that thread for a long time delays updates and responses to input. Distinguish the underlying operation from the work that puts its results on screen. ⁸

flowchart TB
    accTitle: The path from processing to the progress display
    accDescr: Even if the operation reports progress, the display cannot reflect it until the UI processes the update.
    A["Actual processing"] --> B["Report progress"] --> C["Process the UI update"] --> D["Update the screen"]
    E["UI thread blocked"] -.-> C

Figure 8: A frozen display does not necessarily mean the operation itself is frozen.

Conversely, an animation designed to run independently of the actual work can continue spinning while that work waits. “Moving means healthy; stationary means broken” is not a sufficient distinction.

I recommend first recording the display and start time, checking for prompts awaiting input, and comparing counts or logs over time. Treat Task Manager readings as supporting evidence. Before considering termination, check the application’s cancellation procedure and what happens to partial output.

.NET cancellation is also cooperative: requesting cancellation does not itself stop the operation immediately; the operation must respond. ⁹ This is why “canceling” and “canceled” should be separate states. A progress display alone cannot provide a universal number of minutes after which forcing the application to quit becomes safe.

8. Compare three displays of the same operation

Open the progress-bar comparison demo

The demo advances through observations of a fictional workload when you press a button. There is no need to wait, and it does not read, write, or upload files. The first case contains 99 small files and one large file. For each observation, it shows a file-count bar, a transferred-data bar, and the overall task state side by side.

While the final large file is being transferred, the count-based bar remains at 99% even as the data-volume bar grows. When transferred data reaches 100%, the overall state is still “verifying.” Only the next observation marks success. You can see how the same work can look stalled or active solely because of how it is displayed.

flowchart TB
    accTitle: How to read the comparison demo
    accDescr: A single observation of one fictional operation feeds three displays: file count, transferred data, and overall state.
    A["One fictional operation"] --> B["The same observation"]
    B --> C["File-count percentage"]
    B --> D["Transferred-data percentage"]
    B --> E["Overall task state"]

Figure 9: The demo compares three views of one operation, not three different operations.

The second case reproduces the slowdown from section 2 and shows the calculation that turns 10 seconds into 79. It uses the following calculation. This is a deliberately simple educational estimate, not a production implementation of retries, parallel processing, or stage-specific prediction.

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

Use matching units for remaining and rate, such as MiB and MiB/s. A return value of zero means none of the measured workload remains, not that the entire application task has succeeded. For positive remaining work, a zero or unknown speed produces null so that an unknown estimate is not mistaken for “0 seconds remaining.”

9. Aim to avoid misleading users, not merely to look precise

For the design discussed here, I would keep the current stage, measured work, a time estimate only when justified, and the success, failure, or cancellation result separate. Even when combining stage percentages into one bar, a split such as “transfer 80%, verification 20%” represents design weights, not a guarantee of this run’s time allocation.

flowchart TB
    accTitle: Building a progress display from observations
    accDescr: Show the current stage, measured quantities, a time estimate when justified, and the final result as separate information.
    A["Information from the operation"] --> B["Current stage"]
    A --> C["Measured and total work"]
    A --> D["Estimate when justified"]
    A --> E["Success, failure, or cancellation"]

Figure 10: Keep observations and predictions distinct on screen as well.

“Verifying: 400 / 1,000 items; calculating time remaining” can be useful without a countdown. If displaying a timestamp, distinguish “last increase in progress” from “last successful communication with the UI.” Do not update only the latter in a way that makes a stalled task appear to be advancing normally.

The same principle applies to accessibility. HTML’s progress element can represent indeterminate progress by omitting its value. ¹⁰ For a custom ARIA progress indicator, omit aria-valuenow when the value is unknown and provide an accessible name that identifies what is progressing. ¹¹ Both the visual display and the information read aloud should honestly reflect what is known.

10. Frequently asked questions

Does one second remaining without completion mean something has failed?

The display alone cannot decide that. Distinguish an inaccurate estimate, another stage, delayed UI updates, and an actual stall. Both “it is common, so it must be fine” and “a second has passed, so it must be broken” jump to conclusions.

Does 99% mean 1% of the total time remains?

No. Whether the percentage counts files or bytes, the time per unit need not be constant. Multiplying elapsed time by 1% does not give the remaining duration.

Does a spinning animation mean the task is healthy?

An activity indicator and evidence of advancing work are different things. Look at completed work, stages, and logs together. Animation alone does not guarantee that the task can reach successful completion.

Can I show progress without knowing the time remaining?

If the total and completed amounts are known, you can show their ratio. Omit only the countdown when prediction is unreliable. When the total itself is unknown, use an indeterminate indicator with the stage and completed count.

11. Summary: time remaining is a forecast; completion is a result

“One second remaining” does not take a long time because the computer cannot count one second. It takes a long time because observed work is being used to estimate processing time that has not happened yet. Counting units, target discovery, final stages, and delayed UI updates add further complications.

flowchart TB
    accTitle: Questions to ask about a progress display that will not finish
    accDescr: Check what the percentage measures, whether predicted speed changed, whether another stage remains, and whether the UI or the actual operation has stalled.
    A["Percentage of what?"] --> B["Has predicted speed changed?"] --> C["Does another stage remain?"] --> D["UI stall or processing stall?"]

Figure 11: Turn frustration with a number into questions you can investigate.

As a user, look at stages and changes rather than numbers alone. As a developer, do not blend measured work, prediction, and results. More important than repeatedly getting “one second” right is explaining what is happening now and what is still unknown. That is the job of a good progress display.

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Does a task stuck at one second remaining mean something has failed?

The display alone cannot tell you. Distinguish an inaccurate speed estimate, a final processing stage, a stale UI, and an actual stall. Check changes in counts and logs and look for prompts awaiting input. Do not force the application to quit solely because it says one second remaining.

Does 99% mean only 1% of the total time remains?

No. The meaning depends on whether the percentage measures items, bytes, or weighted stages, and those units need not take equal amounts of time. A progress percentage measures a fraction of work, not time remaining itself.

Does a spinning animation prove that the task is healthy?

No. When animation and processing run independently, the animation can continue while the task waits. Distinguish the animation from evidence of completed work, such as counts, stage changes, and logs.

Can I show a progress bar without an accurate time estimate?

Yes. When the total and completed amounts are known, you can show their ratio and omit the time estimate if speed is unstable. When the total itself is unknown, show the stage or completed count rather than inventing a percentage.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.