# alive-progress: Python Progress Bar with Real-Time ETA and Pause Support

> alive-progress is a Python progress bar library that uses a live animated spinner reacting to actual processing throughput, an Exponential Smoothing ETA, multithreaded-safe print and logging hooks, and a unique pause-and-resume mechanism that no other progress bar library documents.

**rsalmei/alive-progress** — A new kind of Progress Bar, with real-time throughput, ETA, and very cool animations!

- Repository: https://github.com/rsalmei/alive-progress
- Stars: 6,311 · Forks: 238
- Language: Python
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rsalmei-alive-progress

## What alive-progress Adds Beyond a Basic Progress Counter

Standard tqdm or the builtin iteration counter tells a developer how many items have been processed. It does not answer the question that matters most during a long data import or model training run: when will this finish? alive-progress targets developers who run lengthy batch jobs, data migrations, and processing scripts in terminals where they need to distinguish a slow run from a crashed one.

The README frames the motivation explicitly: developers have hit enter multiple times on an SSH session to check whether a script was still alive. alive-progress addresses this through a spinner that changes speed in real time to reflect the actual throughput, and through an ETA that uses Exponential Smoothing to account for varying processing rates rather than a naive linear extrapolation.

The library is particularly aimed at Python 3.9 and later users, as declared in setup.py. The README table of contents shows sections on the bar handler, auto-iterating, modes of operation, styles, configuration, custom animations, and advanced features including the pause mechanism. The 3.3 series introduced Python 3.14 support in CI and replaced the grapheme dependency with graphemeu, a maintained fork.

## How the Live Spinner and Multithreaded Updates Work

The spinner reacts to actual throughput, not time elapsed. When processing is fast, the spinner animates quickly. When each iteration takes longer, the spinner slows to match. This visual feedback distinguishes a legitimately slow computation from a frozen or disconnected session.

The update rate is throttled: the README states that 1,000,000 iterations per second results in roughly 60 terminal updates per second. This multithreaded design keeps CPU usage low by decoupling the bar refresh rate from the actual work rate. The bar runs on its own thread and polls the iteration counter at the configured frames-per-second rate.

Print and logging hooks intercept calls to Python's print() and logging module so that log lines during a progress run do not overwrite or corrupt the progress bar. The 3.2 series made these hooks multithreading-safe, so multiple threads writing to stdout are synchronized. The hooks also record which bar iteration each print occurred at and include that position in the output, which is useful for correlating log messages with progress milestones.

The final receipt, printed when the bar completes, includes total items, elapsed time, and observed throughput. As of the 3.3 series, the receipt is available in the alive_bar handle even after the bar has finished, and the elapsed time is exposed with full precision.

## Installing and Running alive-progress

The package is named alive-progress in setup.py. The repository's justfile documents the development install path:

```bash
pip install -r requirements/dev.txt -r requirements/test.txt -e .
```

This installs the development version along with test dependencies. To run the test suite after a development install:

```bash
python -m pytest
```

The requirements/ directory separates dev and test dependencies. The justfile also shows a lint target using ruff with a line length of 100 and a release target that builds via setup.py sdist and bdist_wheel and uploads via twine. The noxfile.py supports running tests across multiple Python versions using nox.

For production use, the install instructions are in the README's "Get it" section. The package is listed on PyPI under the name alive-progress, matching the setup.py name.

## ETA Calculation and the Three Modes of Operation

The ETA uses Exponential Smoothing, which gives more weight to recent throughput measurements than to older ones. This means the ETA adjusts quickly when processing slows down partway through a batch, such as when a later phase of processing involves heavier computation.

The README documents three modes of operation: Auto (the bar advances one step per call to bar()), Unknown (a counter mode without a known total), and Manual (percentage-based progress for non-iterative tasks). In Auto mode, the bar infers the completion percentage from the item count. In Manual mode, the developer calls bar() with an explicit fraction between 0 and 1.

The 3.2 series added support for zero and negative bar increments. Calling bar(0) records no progress, and calling bar(-N) moves the bar backward, which is useful when an iteration fails and needs to be rolled back in the progress count. The 3.3 series also made the bar title and body text mutable after the bar has finished, so the final receipt can be updated with additional context.

## The Pause Mechanism and Loop-Less Use

The pause feature is described in the README as a first: no other progress bar in any language has this feature. When a developer suspends the bar, processing stops and the Python prompt returns. The developer can inspect variables, fix individual items, or call functions manually. Resuming returns to the same progress state as if the bar had never stopped.

This mechanism is useful for data processing jobs where a subset of items fails validation or throws exceptions. Rather than aborting the run and restarting from scratch, the developer pauses, fixes the problematic items in the Python session, and resumes.

The README also documents loop-less use for situations where the total is not known in advance or where the progress updates come from outside a Python for loop. This mode works by calling bar() with explicit counts rather than relying on auto-iteration.

FPS Calibration lets developers tune the update frequency if the default 60 fps is too high for their terminal or too low for their taste. The README documents that forcing animations in PyCharm, Jupyter, and similar environments requires extra configuration, since those environments intercept stdout differently from a standard terminal.

## Custom Animations with the check() Tool

The README describes an animation design tool called check(). It prints the generated frames and animation cycles directly to the terminal and shows them live before they are installed into alive-progress. A developer can see exactly how a custom spinner or bar style will look at each frame of the cycle without writing a full script to test it.

Spinners are built using a Spinner Compiler described in the README. Spinner Factories and Bar Factories generate parameterized families of animations. The README lists a range of ready-made styles and documents how to create new ones by combining sequences, repeating patterns, and applying transformations.

This customisation depth means alive-progress can be integrated into CLI tools that have a distinct visual identity. The styles can be selected by name when configuring the bar, and the configuration system supports global defaults so an application does not need to specify style parameters on every bar call.

## Where alive-progress Is Not the Right Fit

The animated output requires a terminal that honours ANSI escape codes. The README specifically notes that PyCharm, Jupyter notebooks, and similar environments need extra configuration to show animations correctly. In a plain file redirect (python script.py > output.txt), the bar output will not render as intended.

For production monitoring or dashboards that aggregate progress across distributed workers, alive-progress is not designed for that use case. It is a single-process library that reports progress to the local terminal. Multi-process or cross-machine progress aggregation requires a different approach.

The README does not document a structured output format for progress events, so integrating alive-progress with a log aggregation system requires intercepting stdout. The logging hooks help for text logging, but they do not emit JSON or structured events.

The last push was on 2026-05-24. Development appears to be proceeding at a measured pace.

## alive-progress vs tqdm

tqdm is the most widely used Python progress bar library. RELATED SEARCHES for alive-progress include alive-progress vs tqdm, indicating this is a common comparison.

tqdm prioritises simplicity: one import, one context manager or iterator wrapper, and a progress bar appears. Its output is plain text without animated spinners. tqdm integrates with pandas, Jupyter notebooks, and many ML frameworks through explicit support in those libraries. Its documentation covers the basics quickly.

alive-progress offers more display richness at the cost of more complexity. The spinner, the ETA model, the print hooks, and the pause mechanism have no equivalents in tqdm. The check() animation design tool is unique. But alive-progress requires more familiarity to configure, and its terminal animation is a liability in environments where tqdm works without any extra configuration step.

For teams who need a drop-in progress bar across many libraries and environments, tqdm's broad integration wins. For teams building their own Python CLI tools with long-running jobs where terminal feedback quality matters, alive-progress provides capabilities tqdm does not.

## Conclusion

alive-progress is the right choice for Python scripts and data pipelines where developers want ETA feedback that responds to the actual processing rate, print integration without terminal corruption, and the ability to pause a long-running job to fix data mid-run. It is the wrong choice for production monitoring dashboards or terminal-agnostic environments: the animated output requires ANSI escape codes, and PyCharm and Jupyter need extra configuration to show animations. The package is under the MIT license, and the last push was on 2026-05-24.

## FAQ

### How do I create progress bars in Python?

alive-progress wraps a loop with an alive_bar context manager. The bar handler passed into the context is called once per iteration to advance the progress. The library handles the spinner, ETA, and final receipt automatically. Install from PyPI under the name alive-progress.

### Does alive-progress support multithreaded Python code?

Yes. As of the 3.2 series, the print and logging hooks are multithreading-safe. Multiple threads can write to stdout without corrupting the progress bar display, and each print is tagged with the bar position at the time it occurred.

### What makes alive-progress different from tqdm?

alive-progress adds a live spinner that reacts to actual throughput, an Exponential Smoothing ETA, multithreading-safe print hooks, and a unique pause-and-resume mechanism. tqdm is simpler to drop into existing code and integrates directly with pandas and ML frameworks that have explicit tqdm support. alive-progress also provides a check() tool for designing custom animations.

## Sources

- [Issues](https://github.com/rsalmei/alive-progress/issues)
- [License: MIT](https://github.com/rsalmei/alive-progress/blob/main/LICENSE)
- [README](https://github.com/rsalmei/alive-progress/blob/main/README.md)
- [rsalmei/alive-progress on GitHub](https://github.com/rsalmei/alive-progress)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rsalmei-alive-progress