alive-progress is a Python progress bar library for long-running command-line processing, aimed at developers who need live throughput, an accurate ETA, and rich terminal animation instead of a static bar.

What it is

alive-progress is a progress bar package for Python, distributed through PyPI under the MIT licence. It lives in the Python CLI and scripting ecosystem, and it is designed for the case where a lengthy processing loop runs unattended in a terminal, often over SSH. The README frames the project around a common problem: not knowing where a long run has got to, and whether it has finished or crashed. Its central idea is that the bar animates according to actual processing speed, so a spinner visibly speeds up or slows down with throughput and keeps showing that work is still in progress even when a single step takes a long time.

What it concretely replaces is the habit of pressing RETURN repeatedly to confirm that a process has not died or that a remote SSH connection has not frozen, together with the absence of any reliable estimate of when a run will end. Instead of polling by hand, the user gets a live indicator, an ETA, and a final summary. It also replaces the practice of abandoning a run to fix a few items at the Python prompt and starting over, because the bar can be suspended and resumed.

Key capabilities

• A live spinner that reacts to real processing speed, speeding up or slowing down as throughput changes, and making clear that a long task has not crashed or frozen.
• A multithreaded update mechanism that refreshes the display at a fraction of processing speed to keep CPU usage low and avoid terminal spam, with calibration available; the README gives the example of 1,000,000 iterations per second producing roughly 60 updates per second.
• An ETA calculated with an exponential smoothing algorithm, giving the time to completion so workload and time can be planned.
• Automatic print and logging hooks that integrate with existing code and enrich those outputs with the current bar position at the moment they occurred.
• A final receipt printed at the end of processing, listing total items, elapsed time, and observed throughput.
• Detection of underflows and overflows, so hits, misses, or arbitrary counts can be tracked rather than only iterations actually performed.
• The suspend() capability, which returns control to the Python prompt so items can be adjusted or fixed and then the same processing resumed as if it had never stopped.
• A range of ready-made spinner and bar styles, factories for creating custom ones, and a check() tool for designing animations by previewing generated frames and animation cycles, alive, before installation.

Who uses it and how

• Developers running long Python data processing or batch loops in a terminal who need to know whether the job is still alive and how long it has left.
• Users working over SSH on remote machines, where a responsive spinner distinguishes a slow task from a frozen connection.
• Teams processing large item sets who need to fix a subset of items manually mid-run; they suspend the bar, edit the data at the Python prompt, and resume without losing position.
• Codebases already using print or logging, which receive bar position information through the automatic hooks without changes to output handling.
• Workloads tracking counters other than the iteration count, such as hits and misses, using the underflow and overflow detection.

Getting started

Install from PyPI with pip install alive-progress. The package is the only artefact required; the README's badge links point to the PyPI project page for the current version and supported Python versions.

How it compares

No list of paid products replaced by this project appears in the facts, and no competing tool is named. It therefore stands alone in this registry. The README does make one comparative claim: that no other progress bar anywhere in any language offers the suspend and resume capability.

When to use it — and when not to

A self-hoster runs nothing extra beyond a Python environment, since the library is imported rather than deployed as a service, and the facts mention no database, storage, or mail server to operate. It is not the right choice for non-Python projects, or for workloads that are not iterative, where throughput, ETA, and item counts carry no meaning. The available facts are also thin on maintenance detail: the README excerpt is truncated and no release history is provided, so the last push timestamp is the only currency signal available.