My website times out on slow tasks like PDFs. How do I fix that?

This page may contain affiliate links from which Blur Studio earns commissions.

A web request is designed around the assumption that a response comes back fast, generally within a handful of seconds. That assumption breaks the moment the task behind it is genuinely slow: rendering a large, image-heavy PDF, resizing or transcoding an uploaded file, or running a calculation over a big dataset. The request times out not because anything is broken, but because it was never built to wait that long in the first place.

Why this happens specifically

Most hosting platforms, Netlify included, cap how long a standard function or request is allowed to take before it's cut off, since letting requests run indefinitely would make the whole system unpredictable and expensive to run. A regular Netlify function, the kind that responds directly to an incoming request, is built around a response window measured in seconds, not minutes. That's completely fine for the vast majority of what a function does. It's the wrong shape for a task that genuinely needs thirty seconds or several minutes to finish.

The options, from least to most effort

• Do it by hand: generate the report locally yourself and email it. Free, but defeats the point of having it automated on your site.
• A background function: the same idea as a regular function, but built for jobs that take longer, without being bound by the standard request-response timeout.
• A queue service (like Amazon SQS or similar): the right tool once you have a genuinely heavy, ongoing volume of slow jobs, not just an occasional one.
• A custom build: worth it once the workload is heavy, frequent, and specific enough that generic tools start feeling like the wrong shape for the problem.

How a background function actually solves this

The core idea: instead of making the visitor's browser wait for the slow task to finish before anything happens, the request kicks off the job and returns immediately, acknowledging "got it, working on it," while the actual PDF generation or file processing runs separately, outside that tight response window. When it's done, the result gets delivered another way, an email with the file attached, a notification, or the visitor checking back on a status page a minute later.

This is a genuine shift in how the feature behaves, not just a configuration tweak: the visitor no longer sees a spinning loading icon while nervously hoping the page doesn't time out. They get immediate confirmation, and the result follows shortly after through a separate channel. For most "generate my report" or "process my upload" use cases, that's actually a better user experience anyway, not just a workaround for a technical limit.

When a background function still isn't enough

Background functions solve the single-slow-task problem well. What they don't solve cleanly is sustained, heavy compute load, hundreds of PDFs generating simultaneously, continuous video processing, or genuinely compute-intensive work like large-scale image transformation across a big catalog. Netlify's own guidance is direct about this: heavy compute workloads fit better on a regular server built for that purpose, or a GPU-backed service, than on a serverless platform designed around short, bursty tasks.

A queue service like Amazon SQS sits in between: it lets you accept a high volume of job requests reliably, process them at a controlled rate instead of all at once, and retry anything that fails, which matters once you're dealing with real volume rather than an occasional slow request. Setting one up is a more involved piece of infrastructure than a background function, and it's rarely worth the complexity unless you're genuinely running into volume, not just occasional slowness.

A worked example: a real estate site generating comparison reports

A real estate agent's website let visitors request a detailed comparative market analysis report, a PDF pulling in recent nearby sales, photos and a price estimate. Generating it took anywhere from fifteen seconds to over a minute depending on how much data had to be pulled and rendered, and a meaningful share of requests were timing out before the PDF finished, especially the more detailed ones. The agent's first instinct was to try to speed up the PDF rendering itself, which helped a little but didn't fully solve the timeout problem, since some reports were simply going to take longer than any standard request window allowed.

Switching to a background function changed the actual flow: the visitor submits the request and sees an immediate "we're preparing your report, check your email in a couple of minutes" message, while the PDF generates separately without being bound by the standard timeout. The result arrives by email once ready. Beyond fixing the timeout entirely, this turned out to be a better experience than the original design, since visitors weren't staring at a loading spinner wondering if the page had frozen.

Common mistakes when moving to a background function

• Not telling the visitor what to expect. An immediate "got it" response with no explanation of when or how the result will arrive leaves visitors confused about whether anything actually happened. Be explicit: "check your email in a few minutes," not just a vague acknowledgment.
• Assuming a background function removes all limits. It extends the time budget significantly compared to a standard request, but it's still not meant for continuous, heavy, ongoing compute. That's what a queue service or dedicated infrastructure is for.
• Not building in a way to check on failed jobs. If the background process fails partway through, the visitor needs some way to know, rather than waiting indefinitely for an email that's never coming.

What I'd actually tell you

Most "my website times out" problems I see are actually this exact pattern: a single, occasionally-slow task hitting a standard request's time limit, not a sign of heavy sustained load. A background function fixes that specific problem cleanly and is genuinely not a big engineering lift. Don't reach for a queue service or heavier infrastructure until you've actually confirmed that volume, not just occasional slowness, is the real issue; building for a scale problem you don't actually have yet is wasted effort that also makes the simpler fix harder to maintain later.

How I'd approach this

This is a common, well-understood fix: move the slow part of the job to a background function on Netlify, keep the user-facing response immediate, and deliver the result separately once it's ready. If you're genuinely running into volume, not just occasional slowness, I'll tell you plainly that a queue-based setup is the right next step, and help you size it to what you actually need rather than over-building for a scale you're not at yet.