Cloud Functions timeout behavior: when cleanup code is skipped after timeout

The short answer

There is no callback that fires when a Cloud Functions timeout occurs — the runtime terminates the instance abruptly, so no code after that point (including finally blocks) is guaranteed to run. The reliable approach is to detect the timeout before it happens by polling the remaining execution time, and to detect client disconnects by listening for the request close event so you can exit early.

Why cleanup after a timeout is unreliable

Firebase Cloud Functions enforce a hard execution deadline (60 s default in 1st gen, configurable up to 540 s; 2nd-gen HTTP functions can run up to 3600 s). When the deadline fires, the instance is reclaimed without running your remaining code. This means:

• try/finally and process-level hooks are only dependable for synchronous errors and explicit returns, not for timeout termination.
• A client aborting the HTTPS request does not cancel the function — it keeps running (and billing) until it finishes or hits the timeout.

Strategy 1: Poll remaining time and checkpoint early

Track the deadline yourself and bail out with a safety margin before the runtime kills you:

const DEADLINE_MS = 540_000; // match your configured timeout
const SAFETY_MS = 5_000;

exports.longJob = functions.runWith({ timeoutSeconds: 540 })
  .https.onRequest(async (req, res) => {
    const deadline = Date.now() + DEADLINE_MS - SAFETY_MS;

    for (const item of workItems) {
      if (Date.now() > deadline) {
        // Persist progress and hand off the rest
        await db.doc(`jobs/${jobId}`).set({ cursor: item.id }, { merge: true });
        await enqueueContinuationTask(jobId); // Cloud Tasks
        await cleanup(); // runs while time remains
        res.status(202).json({ status: 'continued' });
        return;
      }
      await processItem(item);
    }
    res.status(200).json({ status: 'done' });
  });

Key points:

1. Check the deadline before each unit of work, not once — infrequent checks can still overshoot the cutoff.
2. On the cutoff path, checkpoint state to Firestore and offload the remainder to Cloud Tasks (or Pub/Sub), then run cleanup while you still have execution time.
3. Keep the safety margin larger than your slowest single step plus cleanup duration.

Strategy 2: React to client disconnect

In the Node.js runtime, the request object emits close when the client goes away. Use it to stop early and avoid billed idle time:

let clientGone = false;
req.on('close', () => { clientGone = true; });

for (const item of workItems) {
  if (clientGone) {
    await cancelPendingWork(); // abort unawaited promises, streams, etc.
    return; // exit early; no response needed
  }
  await processItem(item);
}

Caveats:

• close can also fire after a normal response completes, so only treat it as an abort if you haven't sent the response yet.
• Unawaited background promises may keep running after you return — explicitly cancel or await them before exiting.
• Returning early stops your handler, which is what reduces billed duration; verify in the function logs that reported execution time drops.

Verifying the behavior

1. Deploy a test function that sleeps past its timeout with logs before the sleep, after it, and in a finally — you should see only the first log, confirming post-timeout code is dropped.
2. Add the remaining-time check and confirm the cleanup log appears before termination.
3. Abort a request mid-run (e.g., curl --max-time 2) and confirm the close handler fires and billed execution time shrinks.

One detail worth confirming for your case: which runtime and generation you're on — the remaining-time API and request event semantics differ between Node.js, Python, and Go, and between 1st and 2nd gen.