APScheduler is an MIT-licensed Python library that provides task scheduling and job queuing, scaling from a single-process script to multi-node deployments that share a persistent data store.

What it is

Advanced Python Scheduler is a task scheduler and task queue system written in Python and published under the name apscheduler. It comes in both synchronous and asynchronous flavors, which makes it usable in traditional thread-based applications and in asynchronous applications built on asyncio or Trio. It can also be used purely as a job queuing system when scheduling is not required at all. Documentation and examples cover integration with WSGI and ASGI compatible web applications, and the project's documentation lives at https://apscheduler.readthedocs.io/.

The problem it solves is the scheduling code every Python application otherwise writes for itself, together with the separate plumbing needed to run jobs on a timer outside the process. APScheduler supplies the scheduling mechanisms directly, with cron-style, interval-based, calendar-based, and one-off triggers, and it persists schedules and jobs so that they survive process and node restarts. Because that persistent store can be shared, multiple schedulers and workers can be deployed against it to provide a degree of high availability and horizontal scaling, rather than each instance holding its own private, unshared timer state.

Key capabilities

• Built-in triggers cover cron-style scheduling, interval-based scheduling, calendar-based scheduling that runs on intervals of X years, months, weeks, or days always at the same time of day, and one-off scheduling at a specific date and time.
• Combining triggers allow different scheduling mechanisms to be combined, and custom trigger classes can be written and treated no differently from the built-in ones.
• Persistent storage of schedules and jobs uses PostgreSQL, MySQL and derivatives, SQLite, or MongoDB, so schedules survive process and node restarts and can be shared among scheduler and worker instances.
• Event brokers for scenarios with multiple schedulers or workers are PostgreSQL, Redis, and MQTT.
• For a given task (function), the maximum number of simultaneous jobs can be limited, and the amount of time a job is allowed to start late can be limited.
• Jitter adds adjustable, random delays to the run time of each scheduled job.
• The library can be used solely as a job queuing system with no task scheduling at all.

Who uses it and how

• Trivial, single-process cases run the scheduler inside one application process with no shared infrastructure.
• Large deployments spanning multiple nodes run several schedulers and workers against one shared data store for high availability and horizontal scaling.
• Traditional, thread-based Python applications use the synchronous flavor, while asyncio or Trio applications use the asynchronous flavor.
• Teams embedding scheduling in web applications use the documented WSGI or ASGI integration examples.

Getting started

Installation, configuration, and examples are documented at https://apscheduler.readthedocs.io/, with the distribution published as apscheduler. The facts list no Docker image, Compose file, or hosted option, so deployment is as a Python package inside the application.

How it compares

No list of paid products replaced by this project is provided, and the facts name no comparable scheduling tools. Within this registry it stands alone in the Business Software / Scheduling & Event Management category.

When to use it — and when not to

A self-hoster who wants persistent, shareable schedules must operate a database such as PostgreSQL, MySQL, SQLite, or MongoDB, and multi-scheduler or multi-worker deployments additionally require an event broker such as PostgreSQL, Redis, or MQTT. Anyone evaluating the v4.0 series should note the README's explicit warning that it is a pre-release which may change in a backwards incompatible fashion with no migration pathway, and that it must not be used in production. The licence is MIT, which is unambiguous, but the pre-release status is the clearest reason to be cautious.