Startup and shutdown events in FastAPI - Step-by-Step Execution

Concept Flow - Startup and shutdown events

App starts

↓

Run startup event

↓

App ready to handle requests

↓

App receives shutdown signal

↓

Run shutdown event

↓

App stops

When the FastAPI app starts, it runs startup events first. After that, it handles requests. When stopping, it runs shutdown events before fully stopping.

Execution Sample

FastAPI

from fastapi import FastAPI
app = FastAPI()

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

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

This code prints messages when the app starts and stops using startup and shutdown events.

Execution Table

Step	Trigger	Action	Output	State
1	App starts	Run startup_event	Prints 'Starting up...'	App ready
2	App running	Handle requests	Respond to clients	App ready
3	Shutdown signal	Run shutdown_event	Prints 'Shutting down...'	App stopping
4	App stopped	Exit process	No output	App stopped

💡 App stops after running shutdown event on shutdown signal

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
App state	Not started	Ready	Ready	Stopping	Stopped

Key Moments - 3 Insights

Why does the startup event run before the app handles requests?

The startup event prepares the app before it can serve requests, as shown in execution_table step 1 where the app prints 'Starting up...' before becoming ready.

What happens if the shutdown event is not defined?

If no shutdown event is defined, the app stops immediately without running any cleanup code, unlike step 3 where shutdown_event prints a message.

Can startup and shutdown events be asynchronous?

Yes, they can be async functions as in the example code, allowing for async operations during startup and shutdown.

Visual Quiz - 3 Questions

Look at the execution table, what is the app state after step 1?

A Ready

B Stopping

C Not started

D Stopped

💡 Hint

Check the 'State' column in row for step 1 in execution_table

At which step does the app print 'Shutting down...'?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Look at the 'Output' column in execution_table for the shutdown event

If the startup event took longer, which step would be delayed?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Startup event runs at step 1; app becomes ready at step 2 to handle requests

Concept Snapshot

FastAPI runs startup events before handling requests.
Shutdown events run before app stops.
Use @app.on_event("startup") and @app.on_event("shutdown") decorators.
Events can be async for async setup/cleanup.
Startup prepares app; shutdown cleans up resources.

Full Transcript

In FastAPI, startup and shutdown events let you run code when the app starts and stops. When the app starts, it runs the startup event first to prepare resources. Then it handles incoming requests. When the app receives a shutdown signal, it runs the shutdown event to clean up before stopping. You define these events using @app.on_event decorators with 'startup' or 'shutdown'. These functions can be asynchronous to handle async tasks. The execution table shows the app state changing from not started to ready after startup, then stopping after shutdown. This helps manage resources safely during app lifecycle.

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