FastAPI Background Tasks — Core Concepts

What background tasks solve

Web APIs have an implicit contract: respond quickly. Users, mobile apps, and other services calling your API expect answers within milliseconds. But many operations triggered by a request don’t need to finish before the response goes out.

Sending emails, generating reports, updating search indexes, writing audit logs, resizing uploaded images — these can all happen after the user gets their “200 OK.” FastAPI’s BackgroundTasks provides a clean way to schedule this post-response work.

How BackgroundTasks works

You add BackgroundTasks as a parameter to your route function. FastAPI injects it automatically. Then you call add_task() with a function and its arguments:

The task function runs after the response is sent. It executes in the same process, on the same event loop (for async tasks) or in a thread pool (for sync tasks). No extra infrastructure needed.

Sync vs async tasks

FastAPI handles both:

• Sync functions passed to add_task() run in a thread pool, so they won’t block async routes
• Async functions run on the event loop after the response completes

Choose async tasks when the work involves I/O (HTTP calls, database writes). Choose sync tasks when the work is CPU-bound or uses libraries that aren’t async-compatible.

Passing through dependencies

Background tasks integrate with FastAPI’s dependency injection. You can add tasks from within dependencies, not just route functions. This is useful when a shared dependency (like an audit logger) needs to schedule follow-up work regardless of which route was called.

The BackgroundTasks object accumulates tasks as the request flows through dependencies and the route handler. All accumulated tasks execute after the response.

Limitations you need to know

No persistence: Tasks live only in memory. If the server restarts or the process crashes, pending tasks vanish. This is fine for “nice to have” tasks (analytics pings) but dangerous for “must happen” tasks (payment confirmations).

No retries: If a background task fails (exception), it’s gone. There’s no built-in retry mechanism. You’d need to add your own try/except with retry logic inside the task.

No monitoring: You can’t check the status of a background task, cancel it, or know when it finished. It’s fire-and-forget.

Same process: Tasks share memory and CPU with your request handlers. A CPU-heavy background task can slow down your API’s response times for other requests.

When to use something bigger

If you need guaranteed delivery, retries, monitoring, or the ability to distribute work across multiple servers, you’ve outgrown BackgroundTasks. The standard escalation path:

• Celery with Redis or RabbitMQ for distributed task queues
• ARQ for async-native task queues (pairs well with FastAPI)
• Dramatiq for a simpler alternative to Celery

The rule of thumb: if losing a task would mean losing money or data, use a proper task queue. If losing a task means a user gets their email 30 seconds late on next retry, BackgroundTasks is fine.

Common misconception

Developers sometimes confuse BackgroundTasks with async route handlers. An async def route already runs without blocking other requests — but it still blocks its own response until it finishes. BackgroundTasks specifically runs work after the response is sent. They solve different problems and work well together.

The one thing to remember: FastAPI’s BackgroundTasks is perfect for lightweight post-response work that doesn’t need guarantees — but the moment you need reliability, retries, or scaling, graduate to a dedicated task queue.