The bug looks impossible the first time you see it. Your FastAPI service handles hundreds of requests a second in load tests. Then someone adds one endpoint that resizes an image or verifies a JWT with a slow library, and suddenly every request gets slow, not just that one. Health checks time out. A streaming chat that was landing tokens in 200 ms now hangs for seconds. Nothing changed in the other routes, but they all got worse together.
\nThe cause is almost always the same: one blocking call sitting on the event loop. This post is for engineers running an async FastAPI backend who have hit that “why is the whole server slow” moment, or want to avoid it. It covers how the event loop works, how FastAPI decides where your route runs, a repro you can run on your laptop, and the right fix for each kind of slow work.
\nI hit this building the FastAPI backends behind CloudCanvasAI and Archi. There, a stalled event loop does not just slow one request down; it freezes the live SSE stream (Server-Sent Events) that every user is watching.
\nFastAPI is async, and async in Python means one event loop running on one thread per worker process. That loop is not doing many things at once. It does one thing at a time and switches between them very fast, at the points where your code says await.
That is the whole contract. When an async def route hits await client.get(url), it tells the loop “I am waiting on the network; go run someone else.” The loop parks that request, picks up another, and comes back when the network call is ready. A hundred requests can be in flight because, at any instant, ninety-nine of them are parked at an await and only one is actually executing.
\n