A serverless function timeout is the maximum execution window a platform allows before it stops an invocation. It is one of several runtime limits that shape whether a workload fits functions at all.
Memory, execution duration, temporary storage, concurrency, payload size, and scaling controls are not minor configuration details. They are architectural boundaries. A function can be perfectly written and still fail in production if its workload needs more time, more memory, more local scratch space, or more simultaneous executions than the platform permits.
For small teams, the useful question is not “Which provider has the biggest number?” It is which limit will your workload hit first, and what should you do when it does? Sometimes the answer is to raise a setting. Sometimes it is to split work, move files to object storage, cap concurrency, or choose a VM or container instead.
At Raff, we treat runtime limits as a workload-fit check before deployment. That prevents teams from discovering an architectural mismatch only after traffic, file sizes, or processing times grow.
Runtime limits define the safe operating envelope
Every serverless platform places boundaries around an invocation. The exact numbers vary by provider and can change by plan, runtime, account state, or product generation.
The main limits to review are:
| Limit | What it controls | Typical failure when exceeded |
|---|---|---|
| Execution timeout | How long one invocation may run | Function is terminated before completion |
| Memory | How much RAM an instance can use | Out-of-memory failure, crash, or severe slowdown |
| Temporary storage | How much local scratch space is available | File processing or extraction fails mid-run |
| Concurrency | How many executions can run at once | Throttling, queueing, rejected work, or downstream overload |
| Scaling range | How many instances the platform may add | Traffic cannot expand beyond configured capacity |
| Request/response limits | How much data can cross the invocation boundary | Large requests or responses are rejected |
These limits interact. Giving a job more memory may shorten its runtime. Increasing concurrency may solve a traffic bottleneck but overwhelm a database. A longer timeout may let a job finish but also keep failed work running longer before the system gives up.
A runtime limit is not just a platform restriction; it is a signal about where state, files, and long work should live.
The right design starts by identifying the dimension most likely to become the bottleneck.
Function timeout should match bounded work
Timeout is the clearest serverless limit because it creates a hard execution boundary.
If a function has a five-minute timeout and the task needs six minutes, the architecture does not become “almost correct.” The invocation can be stopped before its work finishes. That can leave partial database writes, incomplete files, or an external operation whose final state is uncertain.
A timeout should therefore be longer than the normal execution time but not treated as an unlimited safety net.
Use three numbers when planning:
- normal duration: what the job usually needs;
- high-percentile duration: what slower but healthy executions need;
- hard timeout: the point at which continuing is no longer useful or safe.
For a synchronous user request, the practical limit may be much shorter than the platform maximum. A browser, reverse proxy, API client, payment service, or upstream gateway can give up before the function platform does.
For background work, a longer function timeout can be useful when the task is bounded and independently observable. Raff currently publishes timeouts up to 1 hour by default and up to 24 hours on request for Functions. That is a current product limit, not a recommendation to run every task for hours.
The dedicated Long-Running Serverless Functions guide owns the design of AI, ETL, batch, and durable long-running jobs. The distinction here is simpler: timeout is the execution ceiling; job architecture determines whether it is safe to approach that ceiling.
When work routinely approaches the timeout, do not immediately increase it. First ask whether the workload should be split, checkpointed, handed to an asynchronous path, or moved to always-on compute.
Memory limits affect both capacity and execution behavior
A function's memory setting determines how much working memory the execution environment can use. Memory pressure is common in workloads that parse files, build large in-memory objects, transform images, decompress archives, process data frames, or load substantial dependencies.
The failure mode is not always a clean “out of memory” message. Memory pressure can increase garbage collection, cause runtime instability, or make an otherwise short function much slower.
A useful memory review separates four categories:
- runtime baseline — language runtime and framework overhead;
- application baseline — imported libraries, clients, caches, and initialized objects;
- per-request working set — data needed for one invocation;
- temporary peak — decompression, conversion, serialization, or parallel work that briefly needs more RAM.
Measure peak behavior with realistic inputs rather than the smallest development example.
Raff's current public Functions page shows memory as an editable function setting and uses 256 MB in its deployment example. That is an example/default shown in the product UI, not a published maximum. Raff's public page does not currently state a numeric maximum memory ceiling, so production teams should verify the current dashboard or API limits instead of relying on an invented number.
More memory can sometimes reduce execution time, but that does not automatically make it the cheapest or best configuration. The Serverless Function Pricing guide owns the detailed cost trade-off.
Temporary storage is scratch space, not durable state
Temporary local storage is useful for intermediate work:
- unpacking an archive;
- resizing an image;
- generating a PDF before upload;
- buffering a conversion;
- staging a download;
- creating an intermediate export file.
It should not be treated as the permanent home for application data.
Serverless execution environments can be replaced, scaled down, or recreated. Even when local data happens to survive between warm invocations, that reuse is an optimization opportunity, not a durability guarantee.
A safer pattern is:
Durable input ↓ Function downloads only what it needs ↓ Temporary local processing ↓ Function uploads durable output ↓ Temporary files can disappear safely
For Raff workloads, durable files should normally live in Object Storage, while durable records and job state belong in a database. That keeps correctness independent of whether the next invocation lands on the same execution environment.
Raff's current public Functions page describes Object Storage bindings but does not publish a numeric temporary-storage ceiling. We therefore do not treat a specific scratch-space number as a stable product promise in this guide.
If a workload needs a large persistent filesystem, repeated access to the same local data, or extensive disk-heavy processing, that is a strong signal to compare the function with a VM or container-based runtime rather than trying to stretch ephemeral storage into a filesystem service.
Concurrency limits protect both the platform and dependencies
Concurrency is the number of executions that are in flight at the same time. It is not the same as requests per second.
A fast 20 ms handler can process many requests with relatively little concurrency. A 10-second handler can create substantial concurrency at a much lower request rate because each invocation remains active longer.
The basic relationship is:
longer execution time + more incoming work ↓ more simultaneous invocations
Concurrency has two different failure directions.
Too little available concurrency can cause throttling, delayed work, or a backlog during bursts.
Too much uncontrolled concurrency can overwhelm systems behind the function. A function tier may scale successfully while the database hits its connection limit, a third-party API rate-limits requests, or a legacy service becomes saturated.
That is why the right concurrency setting is not simply “as high as possible.” It should fit the narrowest downstream dependency.
The previous Cold Starts, Concurrency, and Scale-to-Zero guide owns the relationship between burst concurrency, new instances, cold starts, and latency. This guide owns concurrency as a hard capacity and safety boundary.
Raff's public Functions page says autoscaling follows load and shows a default scaling example of 0 → 10 instances. It also states that brand-new accounts run with lower concurrency and scale limits until $10 lifetime paid, after which those account-level restrictions lift automatically. The page does not publish a universal numeric concurrency maximum, so teams should verify the live account limit for production capacity planning.
Hitting a limit should trigger a specific architecture response
A runtime limit is most useful when the team knows what action follows.
Use this decision framework:
| Symptom | Likely limit | First response | Escalation path |
|---|---|---|---|
| Invocation stops before work completes | Timeout | Find where time is spent; remove avoidable blocking | Split/chunk work or use a longer-running model |
| Process crashes on larger inputs | Memory | Measure peak working set; stream/chunk data | Increase memory or move memory-heavy work |
| Local file workflow fails on large artifacts | Temporary storage | Stream data and upload outputs early | Use object storage or filesystem-based compute |
| Bursts are throttled | Concurrency/scaling | Measure in-flight work and configured scale | Raise safe capacity if dependencies can support it |
| Database/API becomes unstable during scale-out | Downstream capacity | Cap concurrency and reuse connections carefully | Add queueing, pooling, or redesign dependency path |
| Client gives up before function finishes | End-to-end timeout | Measure client/gateway timeout separately | Make work asynchronous |
The important distinction is between a configuration problem and a workload-shape problem.
If the workload is comfortably inside the platform envelope and a setting is simply too conservative, adjust the setting. If normal production behavior repeatedly presses against several limits at once, changing numbers can postpone rather than solve the mismatch.
When a function needs maximum duration, maximum memory, large persistent disk, and constant concurrency at the same time, the problem is usually the compute model—not four independent settings.
That is the point where Serverless Functions vs VMs becomes the more useful decision guide.
Raff gives long-running workloads more timeout headroom
Raff Functions differs from many short-duration FaaS products in one area that directly matters to runtime-limit planning: the published execution window is much longer.
The current product page states:
- timeout settings are editable after creation;
- Functions run up to 1 hour by default;
- workloads can run up to 24 hours on request;
- memory and scaling are editable settings;
- the current deployment example shows 256 MB, 5 minutes, and 0 → 10 scaling;
- autoscaling follows load and idle functions can scale to zero;
- new accounts have lower concurrency and scale limits until $10 lifetime paid.
Those published values should be read carefully. The 256 MB, 5-minute, and 0→10 values are examples/defaults shown in the product experience, not maximum memory, timeout, or concurrency claims. Raff's public page separately publishes the 1-hour default and 24-hour-on-request duration ceiling.
We deliberately do not publish a guessed maximum for memory or temporary storage in this guide because the current public Functions page does not state one. For those dimensions, the live dashboard/API is the correct source before a production deployment.
From an architecture perspective, Raff's longer timeout means more bounded background work can remain in the Functions model instead of being moved solely because of a short execution ceiling. It does not remove the need for durable state, object storage, safe concurrency, or a VM when the workload genuinely needs a persistent server environment.