Dora NodaTwenty-six seconds. That is the longest a Netlify serverless function is allowed to think — 10 seconds on the free tier, 26 on every paid plan — and for years it was the hard line between what the platform could do and what it could not. API glue, form handlers, SSR routes: fine. Anything that takes longer than half a minute: somebody else's problem.
In 2026 Netlify finally crossed that line. Its durable execution story, Async Workloads, turns serverless functions into durable, event-driven workflows with persisted state, automatic retries, and run times up to 15 minutes. The verdict up front: the timeout gap is closed, but the persistent-service gap is not. If you picked Netlify for its frontend strengths and have been waiting for permission to move your backend there too, here are the numbers, the credit math, and the list of things that still do not fit.
What teams actually picked Netlify for
To judge the backend story fairly, start with what Netlify is genuinely best at. Nobody chose Netlify because they needed long-running compute. They chose it because the frontend workflow is close to perfect: push to git, get a global deploy; open a pull request, get a preview URL for free (preview and branch deploys cost zero credits to this day); serve everything off a global edge CDN without touching a cache header.
Around that core sits a ring of frontend-native primitives: form handling without a backend endpoint, Identity for auth, Image CDN for responsive assets, and serverless functions as glue — just enough backend to power an API route, an SSR handler, or a signup webhook. The functions were never the product. They were the connective tissue around a static-and-edge product, and their limits reflected it: small memory, short timeouts, no state between invocations.
That context matters because it sets the bar the backend story has to clear. The question is not whether Async Workloads are better than a 26-second function — they obviously are. It is whether a platform shaped around deploys-and-edges can grow the second shape, persistent backend compute, without the result feeling like an escape hatch from its own timeout.
The durable answer: Async Workloads
Async Workloads reframe a Netlify function as a durable unit of backend work. You wrap a handler in asyncWorkloadFn, trigger it by sending an event, and Netlify provides what plain functions never had: durable event delivery, persisted state between steps, automatic retries with exponential backoff, a FIFO queue with per-event priorities, delayed execution, dead-letter handling, and autoscaling. A multi-step provisioning-and-billing flow that used to need hand-rolled checkpoint logic to survive a timeout can now persist progress between steps and resume instead of restarting.
The honest footnote is in Netlify's own docs: defining workloads provisions serverless functions and blobs internally, and the capabilities and limitations of serverless functions apply to workloads unless explicitly noted. Durable here means the workflow survives failure, not that any single execution escapes the serverless envelope. Per-execution run time still tops out around 15 minutes, the same ceiling as background functions.
The full ladder, with what each rung can and cannot run:
| Tier | Timeout | Retries / state | Fits | Does not fit |
|---|---|---|---|---|
| Sync function (Free) | 10 s | None | Form handler, auth callback | Any external API slower than 10 s |
| Sync function (paid) | 26 s | None | SSR route, API glue | Report generation, batch fan-out |
| Scheduled function | 30 s | Cron trigger, no state | Nightly ping, cache warm | Any job with real work per tick |
Background function (-background) | 15 min | Fixed retries only, no persisted state | Scrapes, batch jobs that tolerate restarts | Flaky multi-step flows needing resume |
| Async Workload | ~15 min per execution | Exponential-backoff retries, persisted state, FIFO queue, DLQ | Multi-step workflows, provision-and-bill flows, resilient AI pipelines | Anything needing more than 15 min in one execution |
The jump from row four to row five is the real release: plain background functions retry on a fixed schedule with no backoff configuration, no dead-letter queue, and no persisted state, so a transient upstream hiccup at minute 14 silently drops the work. Async Workloads keep the 15-minute execution envelope but make everything inside it resumable. That is a meaningful upgrade for exactly one class of workload: jobs that fit in 15 minutes but kept dying on retries.
The credit math
Compute on Netlify now bills from a single pool. Since September 2025 all new accounts are on credit-based pricing, and since the April 2026 update the Pro plan is a flat $20 per month for 3,000 credits with unlimited seats. The meter rates that matter for backend work: compute at 10 credits per GB-hour, bandwidth at 20 credits per GB, production deploys at 15 credits each, web requests at 2 credits per 10,000. At the Pro rate of $20 per 3,000 credits, one credit is about two-thirds of a cent — cheap until a worker starts burning GB-hours around the clock.
Run two realistic workers against the 3,000-credit pool:
- Quiet worker — a nightly reconciliation job averaging 2 hours a day at 512 MB: 60 hours a month × 0.5 GB × 10 credits = 300 credits, one-tenth of the Pro allowance. Comfortable, with room left for deploys, bandwidth, and requests.
- Busy worker — an event-driven pipeline averaging 12 hours a day at 1 GB: 360 GB-hours × 10 credits = 3,600 credits — the entire Pro pool consumed by one worker, before a single deploy, request, or gigabyte of bandwidth. Everything after that comes from top-up packs.
And the limiting case that settles the always-on question: a service doing real work 24/7 at 1 GB burns 720 GB-hours, or 7,200 credits — roughly $48 at Pro rates — more than double the allowance. Netlify will sell you the credits (July 2026 added rollover tiers for heavier pools), but the meter is telling you something the marketing does not: this pool was sized for bursty frontend-adjacent compute, not for processes that never sleep. A backend worker that is busy enough to justify existing is busy enough to outgrow the flat-rate pool it runs in.
What still does not fit
Async Workloads move the ceiling from 26 seconds to 15 resumable minutes. Everything below still sits above it, and the list is the actual backend:
- No persistent processes. There is no Netlify primitive for "this program runs until I stop it." In-memory sessions, connection pools held open across requests, and state that lives in the process rather than in a Blobs round-trip have no home. Serverless functions spin down; durable workflows persist state, not processes.
- No long-lived connections. A WebSocket server, a streaming proxy, or anything that holds a socket open for hours cannot be built from 15-minute executions, however durable. Teams that need persistent connections still reach for a host with a real process model.
- The 15-minute envelope remains. Durable means resumable, not unbounded. A training job, a large migration, or a video pipeline that needs 40 continuous minutes must still be chopped into 15-minute executions with persisted checkpoints — better than dying at 26 seconds, but still the platform's shape imposed on your workload instead of the other way around.
- No arbitrary daemons or sidecars. No background supervisor, no co-located cache, no stateful cron beyond the 30-second scheduled-function tick. Each workload is one function-shaped thing triggered by events.
- The database story is still metered. Netlify Database bills compute and bandwidth from the same credit pool (storage was free only until July 1, 2026). A chatty backend worker pays for every query twice: once in function compute, once in database egress.
Contrast that with what a backend-first platform does natively: push a repo, get a service that boots, binds a port, holds connections open, keeps pools warm, and runs until you redeploy it — on a machine whose cost is the machine, not a per-GB-hour meter competing with your deploy budget. On a Cluster-API-managed fleet that service is a Deployment with a health check, not a workflow definition fighting a 15-minute execution cap. Netlify grew a durable escape hatch out of its timeout; it did not grow a process model.
Stay or move: a decision guide
The frontend/backend line is blurring, but it has not moved as far as the launch framing suggests. A simple rule of thumb:
- Stay on Netlify if your backend is bursty and bounded: webhooks, provisioning flows, notification fan-out, nightly jobs, AI pipelines whose steps fit in 15 minutes. Async Workloads are genuinely the right tool here — durable delivery plus retries plus a queue, with no infrastructure to manage.
- Move the backend off if it is always-on, stateful, or connection-oriented: persistent APIs with warm pools, WebSocket services, workers busy enough to burn thousands of credits a month, or anything that wants to just run. That workload was never serverless-shaped, and 15 resumable minutes do not make it so.
There is a reasonable middle path: keep the frontend where the frontend workflow is best in class, and run the backend as persistent services on infrastructure you control, called over HTTPS from the edge. That split — Netlify for deploys-and-edges, owned machines for processes-that-run — plays each side's strengths instead of asking either to be something it is not.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
