Why Startup and shutdown events in FastAPI? - Purpose & Use Cases

The Big Idea

Discover how to make your app start and stop like a pro, without messy code everywhere!

The Scenario

Imagine you have a web app that needs to connect to a database and load some settings every time it starts, and close connections cleanly when it stops.

Without special handling, you have to write this setup and cleanup code everywhere, risking mistakes.

The Problem

Manually managing startup and shutdown tasks is tricky and error-prone.

If you forget to close a database connection, your app can leak resources and crash later.

If you don't load settings properly, your app might behave unpredictably.

The Solution

FastAPI's startup and shutdown events let you run code exactly when your app starts and stops.

This keeps your setup and cleanup organized, safe, and automatic.

Before vs After

✗ Before

def start_app():
    connect_db()
    load_settings()

# but what about shutdown?

# scattered cleanup code elsewhere

✓ After

@app.on_event('startup')
async def startup():
    await connect_db()
    load_settings()

@app.on_event('shutdown')
async def shutdown():
    await close_db()

What It Enables

You can ensure your app always prepares and cleans up resources reliably, improving stability and performance.

Real Life Example

A chat app connects to a message broker on startup and disconnects on shutdown, preventing lost messages and resource leaks.

Key Takeaways

Manual resource management is risky and scattered.

Startup and shutdown events centralize setup and cleanup.

This leads to safer, cleaner, and more reliable apps.

Practice

1. What is the main purpose of using @app.on_event("startup") in a FastAPI application?

easy

A. To define API routes for the application.

B. To handle HTTP requests from clients.

C. To shut down the server immediately.

D. To run code when the application starts, like initializing resources.

Solution

1. Step 1: Understand the startup event role

   The @app.on_event("startup") decorator marks a function to run when the app starts, useful for setup tasks.

2. Step 2: Differentiate from other app parts

   Handling requests or shutting down are different concerns; startup is specifically for initialization.

3. Final Answer:

   To run code when the application starts, like initializing resources. -> Option D

4. Quick Check:

   Startup event = run code at app start [OK]

Hint: Startup event runs code once when app launches [OK]

Common Mistakes:

• Confusing startup with request handling
• Thinking startup runs multiple times per request
• Mixing startup with shutdown event

2. Which of the following is the correct syntax to define a shutdown event handler in FastAPI?

easy

A. @app.on_event("start")
def cleanup():
print("Cleaning up")

B. @app.shutdown_event
def cleanup():
print("Cleaning up")

C. @app.on_event("shutdown")
def cleanup():
print("Cleaning up")

D. @app.event("shutdown")
def cleanup():
print("Cleaning up")

Solution

1. Step 1: Recall correct decorator for shutdown

   The correct decorator is @app.on_event("shutdown") to run code when the app stops.

2. Step 2: Check syntax correctness

   Options A, B, and D use incorrect decorator names or syntax.

3. Final Answer:

   @app.on_event("shutdown")\ndef cleanup():\n print("Cleaning up") -> Option C

4. Quick Check:

   Shutdown event decorator = @app.on_event("shutdown") [OK]

Hint: Shutdown event uses @app.on_event("shutdown") exactly [OK]

Common Mistakes:

• Using wrong event name like "start" instead of "shutdown"
• Missing @app.on_event decorator
• Using non-existent decorators like @app.shutdown_event

3. Consider this FastAPI code snippet:

from fastapi import FastAPI
app = FastAPI()

@app.on_event("startup")
async def startup_event():
    print("Starting app")

@app.on_event("shutdown")
async def shutdown_event():
    print("Stopping app")

@app.get("/")
async def read_root():
    return {"message": "Hello"}

What will be printed when the server starts and then stops?

medium

A. Stopping app (on start), Starting app (on shutdown)

B. Starting app (on start), Stopping app (on shutdown)

C. Only Starting app when server starts

D. No output printed at all

Solution

1. Step 1: Identify startup and shutdown prints

   The startup_event prints "Starting app" when the app starts, and shutdown_event prints "Stopping app" when the app stops.

2. Step 2: Understand event timing

   These events run once each: startup at launch, shutdown at server stop.

3. Final Answer:

   Starting app (on start), Stopping app (on shutdown) -> Option B

4. Quick Check:

   Startup prints "Starting app", shutdown prints "Stopping app" [OK]

Hint: Startup prints on launch, shutdown prints on stop [OK]

Common Mistakes:

• Swapping startup and shutdown outputs
• Expecting prints on every request
• Thinking no output occurs without explicit call

4. This FastAPI code is intended to print a message on shutdown but does not work:

from fastapi import FastAPI
app = FastAPI()

def shutdown_event():
    print("App is stopping")

app.on_event("shutdown", shutdown_event)

What is the problem?

medium

A. The decorator syntax is incorrect; should use @app.on_event("shutdown") above the function.

B. FastAPI does not support shutdown events.

C. The function name must be shutdown_handler, not shutdown_event.

D. The function must be async to work as an event handler.

Solution

1. Step 1: Check decorator usage

   The code uses app.on_event("shutdown", shutdown_event) which incorrectly passes two arguments to on_event; it expects only the event name and returns a decorator to apply to a function.

2. Step 2: Identify common mistake

   FastAPI expects the decorator syntax @app.on_event("shutdown") placed above the function definition for clarity and proper registration.

3. Final Answer:

   The decorator syntax is incorrect; should use @app.on_event("shutdown") above the function. -> Option A

4. Quick Check:

   Use @app.on_event("shutdown") decorator syntax [OK]

Hint: Always use @app.on_event("shutdown") decorator syntax [OK]

Common Mistakes:

• Assuming function must be async (it can be sync)
• Using wrong function names
• Believing FastAPI lacks shutdown support

5. You want to open a database connection when your FastAPI app starts and close it when it stops. Which code correctly uses startup and shutdown events to do this?

from fastapi import FastAPI
app = FastAPI()
db = None

# Option A
@app.on_event("startup")
async def connect_db():
    global db
    db = "Connected"

@app.on_event("shutdown")
async def close_db():
    global db
    db = None

# Option B
@app.on_event("startup")
def connect_db():
    db = "Connected"

@app.on_event("shutdown")
def close_db():
    db = None

# Option C
@app.on_event("startup")
async def connect_db():
    db = "Connected"

@app.on_event("shutdown")
async def close_db():
    db = None

# Option D
@app.on_event("startup")
async def connect_db():
    global db
    db = None

@app.on_event("shutdown")
async def close_db():
    global db
    db = "Connected"

hard

A. Option A correctly manages the global db connection on startup and shutdown.

B. Option B correctly manages db without global keyword.

C. Option C correctly manages db asynchronously without global keyword.

D. Option D reverses connection and disconnection logic.

Solution

1. Step 1: Understand global variable usage

   Since db is defined outside functions, to modify it inside functions, global db is needed.

2. Step 2: Check startup and shutdown logic

   The correct version uses global db in both async event handlers, setting db = "Connected" on startup and db = None on shutdown. Versions without global db create local variables. One version reverses the connection and disconnection logic.

3. Final Answer:

   Option A correctly manages the global db connection on startup and shutdown. -> Option A

4. Quick Check:

   Use global to modify external variables in event handlers [OK]

Hint: Use global keyword to modify external variables inside event functions [OK]

Common Mistakes:

• Forgetting global keyword causes local variable shadowing
• Reversing startup and shutdown logic
• Assuming async is required for all event handlers