Vercel Function Timeout — Fix 504 and FUNCTION_INVOCATION_TIMEOUT

1. Identify whether it is Vercel or an upstream API

Open your deployment in the Vercel dashboard and go to the Functions tab. A Vercel-side timeout shows the message FUNCTION_INVOCATION_TIMEOUT with a duration equal to your plan limit. If the log shows a network error from inside your code (e.g. FetchError: network timeout or an Axios ECONNABORTED) the upstream service hung — Vercel itself was still running.

// Always add an explicit timeout to external fetch calls
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), 8000); // 8 s

try {
  const res = await fetch('https://slow-api.example.com/data', {
    signal: controller.signal,
  });
  const data = await res.json();
  return Response.json(data);
} catch (err) {
  if (err instanceof Error && err.name === 'AbortError') {
    return new Response('Upstream API timed out', { status: 504 });
  }
  throw err;
} finally {
  clearTimeout(id);
}

2. Increase maxDuration for Serverless Functions

Set maxDuration in vercel.json under the functions key, or export the constant directly from the route file. The value is in seconds and is silently clamped to your plan maximum.

// vercel.json — apply to a specific function path
{
  "functions": {
    "api/heavy-task.ts": {
      "maxDuration": 60
    }
  }
}

// Next.js App Router — export from the route file instead
// app/api/heavy-task/route.ts
export const maxDuration = 60; // seconds (Pro plan)

export async function POST(req: Request) {
  // your long-running logic here
}

• Edge runtime ignores maxDuration: if your route has export const runtime = 'edge', remove it and let the function run as a Serverless Function to benefit from maxDuration.
• Verify in deployment output: after deploying, the Functions tab shows the configured maxDuration next to each function — confirm the value was accepted.

3. Use streaming to avoid visible timeouts

Vercel measures function execution time from the first invocation to the last byte sent. If you start streaming immediately, the connection stays open without triggering an early timeout — and the client receives data progressively instead of waiting for the full response. This is the standard pattern for AI completions and large data exports.

// app/api/stream/route.ts
export const maxDuration = 60;

export async function GET() {
  const encoder = new TextEncoder();

  const stream = new ReadableStream({
    async start(controller) {
      for (let i = 0; i < 10; i++) {
        // simulate chunked work
        await new Promise(r => setTimeout(r, 4000));
        controller.enqueue(encoder.encode(`chunk ${i}\n`));
      }
      controller.close();
    },
  });

  return new Response(stream, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  });
}

4. Offload work to a background queue (QStash or Vercel Cron)

Work that exceeds 60 seconds even on Pro — report generation, batch AI processing, large file transforms — must be decoupled from the HTTP request entirely. The pattern: the user-facing endpoint returns 202 Accepted immediately and enqueues a job; a separate worker endpoint does the heavy work on its own schedule.

// app/api/enqueue/route.ts — returns immediately
import { Client } from '@upstash/qstash';

const qstash = new Client({ token: process.env.QSTASH_TOKEN! });

export async function POST(req: Request) {
  const body = await req.json();

  await qstash.publishJSON({
    url: `${process.env.VERCEL_URL}/api/worker`,
    body,
    retries: 3,
  });

  return Response.json({ status: 'queued' }, { status: 202 });
}

// app/api/worker/route.ts — does the heavy work
// vercel.json sets maxDuration: 300 for this path (Enterprise)
export const maxDuration = 300;

export async function POST(req: Request) {
  const payload = await req.json();
  // long-running processing here ...
  return Response.json({ done: true });
}

For scheduled batch work (nightly exports, hourly syncs) use Vercel Cron Jobs configured in vercel.json — they invoke a function on a cron schedule rather than on user request, so you are not racing against an HTTP timeout.

// vercel.json — cron job example
{
  "crons": [
    {
      "path": "/api/nightly-sync",
      "schedule": "0 2 * * *"
    }
  ]
}