Vercel 504: FUNCTION_INVOCATION_TIMEOUT (task timed out)

Fix it yourself

Follow the repair

1. Confirm which route times out and how long it actually runs. In Vercel, open your project's Logs and filter for the failing path, or reproduce the request and watch which call returns the 504. Note the duration Vercel reports — if the function dies at exactly your limit every time, the work simply needs longer than it is allowed. Also test the same route's pieces separately: if the database query or the AI call is slow when run on its own, you have found what the function is waiting on.
2. Raise the time limit for that route if your plan allows more. In a Next.js route file, one line sets the ceiling for that function:

   // app/api/generate/route.ts
   export const maxDuration = 60; // seconds
   
   export async function POST(req: Request) {
     // your existing handler
   }

   On the Hobby plan, functions default to 10 seconds and can be raised to at most 60. On Pro, you can raise maxDuration up to 300 seconds. Set it on the slow routes only, and treat this as buying headroom, not as the cure — a route that needs the full allowance on every request is a route whose design wants step 3 or 4.
3. Make the wait itself shorter. Attack whatever the function is waiting on. Run independent calls together instead of in a queue:

   // slow: each call waits for the one before
   const user = await getUser();
   const orders = await getOrders();
   
   // faster: both start at once
   const [user, orders] = await Promise.all([getUser(), getOrders()]);

   For databases: request only the fields and rows you need, add an index for the column you filter or sort by, and check geography — a function running in one region querying a database on another continent pays a travel toll on every single query. In Vercel's project settings you can set the function's region to sit near your database, which is often the single biggest speed-up available.
4. Move slow work off the request entirely. If the job genuinely takes a minute, no visitor should stand there holding the page open. Change the shape of the feature: the route starts the job, saves a "processing" record, and replies immediately with an ID; the slow work continues in the background (a queue or background-job service such as Inngest, Trigger.dev, or QStash, or a Vercel Cron job for scheduled work); the page checks back — or receives a webhook — and shows the result when it lands. This is how AI generation features survive in production: the request takes a second, the generation takes its time elsewhere.
5. For AI calls specifically, stream the answer. If you are calling an AI model, return the response as a stream instead of waiting for the complete text before sending anything. The visitor sees words arriving within a second or two, which turns a tense 40-second hang into a responsive page. Streaming does not repeal the clock — the function still has to finish within its maxDuration — so pair it with the raised limit from step 2, and if generations regularly run past even that, move them to the background pattern in step 4.
6. Know when the real fix is the plan, and when Edge helps. If you are on the Hobby plan and the feature honestly needs more than 60 seconds inside one request, that is a plan ceiling, not a bug: Pro raises the ceiling to 300 seconds. Switching a route to the Edge runtime starts it faster and closer to visitors, but Edge has its own strict CPU limits and no access to some Node features — it suits quick, light work, and it does nothing for a request whose time is spent waiting on a distant database. Pick the tool that matches where your seconds actually go.