Lambda "Task Timed Out After 3.00 Seconds": Real Fix
The direct fix for "Task timed out after 3.00 seconds" is to raise your function's configured timeout above the 3-second default, up to a hard ceiling of 900 seconds (15 minutes) — but here's the part almost nobody tells you: raising the timeout to 900 seconds fixes nothing if the request is arriving through Amazon API Gateway, because Gateway will still cut the connection at 29 seconds by default, no matter what number you typed into Lambda's console.
What "Task Timed Out After 3.00 Seconds" Actually Means
Every new Lambda function is created with a timeout of 3 seconds. That number is not a bug or a leftover default someone forgot to change — it's Lambda's built-in safety valve, the maximum amount of time your code is allowed to run before AWS forcibly stops it. When your logs show "Task timed out after 3.00 seconds," it means exactly one thing happened: the clock ran out before your function returned a result, and Lambda pulled the plug.
The 3-second default was set for a reason. It's a safety valve, not a bug: it stops a runaway or infinite-looping function from burning compute (and your bill) indefinitely. You can raise it in 1-second increments up to a hard maximum of 900 seconds — 15 minutes — and that ceiling applies no matter how much memory, provisioned concurrency, or account-level muscle you throw at the function. There is no tier, no support ticket, and no service quota request that gets a single Lambda invocation past 15 minutes.
🙋♂️ Jake's Reality Check
"So if I just crank the timeout up to the max, this goes away forever, right? Why wouldn't everyone just do that?"
Ethan doesn't sugarcoat it: "Because 'it stopped erroring' and 'it's fixed' are two different things." A function that quietly takes 40 seconds instead of failing at 3 is still slow, still costs more per invocation, and still hides the real problem — a slow query, a cold VPC connection, a downstream service having a bad day. The timeout error was doing you a favor by making the problem loud.
Default, Maximum, and the Exceptions That Aren't 900
The 900-second figure is the maximum for the function's own configured timeout. But several event sources cap it lower before your setting even matters, because the poller that feeds them records has its own commitments to keep. Streaming and message-broker sources — Amazon MSK, self-managed Apache Kafka, Amazon DocumentDB, and Amazon MQ for ActiveMQ and RabbitMQ — only support functions with a maximum timeout of 14 minutes, not 15. It's a small difference until you've set a function to exactly 900 seconds and the event source mapping refuses to save.
| Where the function runs | Max function timeout | Why it's different |
|---|---|---|
| Direct invoke, console test, CLI, most triggers | 900 seconds (15 min) | Lambda's own hard ceiling — no exceptions, no quota increase possible |
| Amazon MSK, self-managed Kafka, DocumentDB, Amazon MQ | 840 seconds (14 min) | These event source mappings reject a function timeout above 14 minutes |
| Behind Amazon API Gateway (default) | 29 seconds | Gateway's own integration timeout, independent of the function's setting |
| Called from a Step Functions Express workflow | Effectively 5 minutes | The whole Express execution — not just this one step — is capped at 5 minutes |
How to Raise the Timeout
If you've read this far and you're confident the function genuinely needs more time — not just papering over a slow dependency — here's every way to change it.
- Open the function in the Lambda console. Go to the Functions page and choose your function by name.
- Go to Configuration → General configuration. This tab holds timeout, memory, and ephemeral storage together, since raising one often means reconsidering the others.
- Choose Edit, then set Timeout to any value between 1 and 900 seconds, entered as minutes and seconds.
- Save. The new value applies to every invocation from that point forward — no redeploy needed.
For automation, the AWS CLI does the same thing in one line:
aws lambda update-function-configuration \
--function-name my-function \
--timeout 120
If the function is defined with AWS SAM, set the Timeout property under the function's resource in template.yaml and run sam deploy. Whichever route you use, treat the number as a deliberate engineering decision, not a default you nudge upward every time an alarm fires.
Why Raising the Number Alone Might Not Fix Anything
This is the part most guides skip, and it's the reason the error comes back after you've already "fixed" it once. Setting the function's own timeout to 900 seconds only controls one clock among several. Any of the others can still cut the request off first, and when that happens the error you see often won't even say "Lambda" — it'll say "504 Gateway Timeout" or "endpoint request timed out," which sends people down completely the wrong troubleshooting path.
⚠️ What this actually breaks
A function set to 900 seconds but invoked through API Gateway with default settings will still be killed at 29 seconds by Gateway, every single time, regardless of how much headroom you gave Lambda. The extra 871 seconds you configured are simply never reachable through that path.
Jake pushes back on this: "The docs make it sound like 29 seconds is basically written in stone. Why would AWS quietly let people raise it if it's supposed to be a hard rule?" Ethan doesn't fully let him off the hook: "It's still the right default for anyone who hasn't proven they need more. Raising it should feel like a deliberate trade-off you asked for — a quota increase and a throttling conversation — not the first knob you turn the moment something's slow."
The Other Timeouts Hiding Around Your Function
Most write-ups treat API Gateway's 29-second cap as an immovable wall. It isn't, anymore — since mid-2024, AWS lets you raise a Regional or private REST API's integration timeout past 29 seconds, though doing so can require a reduction in your account's throttle quota, and it's still not available for edge-optimized APIs. That's a genuine, useful escape hatch that a lot of older articles simply don't mention because it didn't exist when they were written.
| Layer | Default limit | Can it be raised? |
|---|---|---|
| API Gateway REST API integration | 29 seconds | Yes, for Regional/private APIs, via a service quota increase (throttle trade-off) |
| SQS visibility timeout (Lambda as consumer) | Must be ≥ 6× the function timeout, plus the batching window | Yes — you set it on the queue; Lambda refuses to save the event source mapping otherwise |
| Step Functions Express workflow | 5 minutes total | No — switch to a Standard workflow (up to 1 year) instead |
| MSK / Kafka / DocumentDB / Amazon MQ event source | 14 minutes | No — hard cap on the event source mapping itself |
The SQS row deserves a second look, because it runs the opposite direction of the others: Lambda actually validates it. If your function's timeout is set higher than the source queue's visibility timeout, Lambda will reject the update to the event source mapping outright. And even when it's technically valid, AWS recommends the visibility timeout be at least six times the function's configured timeout — the extra headroom exists so Lambda has room to retry a batch if your function gets throttled mid-processing, without a second worker picking up the same messages.
Finding What's Actually Slow, Before You Touch the Number
CloudWatch Logs already contain the answer for most timeouts — you just have to know which line to read. Every invocation ends with a REPORT line showing Duration, Billed Duration, and Init Duration — that last one is your cold-start cost, separate from the function's actual work.
- Pull the last 20 timed-out invocations from CloudWatch Logs Insights. Look for a pattern: is it always the first request after idle time (cold start), or does it happen mid-traffic too?
- Check
Init Durationversus your timeout. A VPC-attached function establishing a fresh ENI, or a large deployment package unzipping, can eat several seconds before your handler code even runs. - Trace the request with AWS X-Ray if downstream calls are involved. A slow RDS query, an S3 download, or a third-party API is the most common real cause — and X-Ray shows exactly which hop is slow instead of leaving you guessing.
- Compare average duration to p99, not p95. Timeouts are a tail-latency problem. The average tells you almost nothing about why the slowest 1% of requests are failing.
The Usual Suspects, Cheapest Fix First
Before reaching for the timeout slider, work down this list — each item is cheaper and more durable than just buying more seconds.
Downloads or uploads larger than expected
Pulling a file from S3, or writing one back, scales with object size. If your test payloads were small and production ones aren't, the function was never actually fast — your tests just never exercised the slow path.
A downstream service that's slow to respond
Databases, third-party APIs, and other Lambda functions called synchronously all become part of your function's own duration. If the dependency itself is the bottleneck, a bigger timeout just makes your function wait longer for someone else's problem, at your expense.
More computational work than the test data implied
Image processing, large JSON transforms, and anything with nested loops scale with input complexity, not request count. Production traffic almost always includes bigger, messier inputs than whatever sample you used during development.
Cold starts on a VPC-attached function
A function attached to a VPC has to provision networking (an elastic network interface) before it can run. This mostly affects the very first invocation after a deployment or idle period; provisioned concurrency keeps a pool of pre-warmed environments ready specifically to avoid this cost on latency-sensitive paths. Ethan's take on it: "Provisioned concurrency solves the cold start, but it isn't free — you're paying for warm capacity whether traffic shows up or not. I'd only turn it on for the one endpoint that genuinely needs sub-second latency, not blanket it across every function in the account."
Special Case: Lambda Triggered by Amazon MSK
If your search brought you here specifically for MSK or Kafka, the mechanics are a little different from a plain invoke, and the 14-minute cap from the table above is only the start. Lambda reads messages sequentially per Kafka partition and hands them to your function in batches — the default batch size is 100 records for MSK, versus 10 for SQS. Offsets only commit to the Kafka cluster after your function successfully finishes processing the whole batch.
That last detail matters for timeouts specifically: if your function times out partway through a large batch, none of that batch's offsets have committed yet. Lambda retries the entire batch — not just the records it hadn't reached — until processing succeeds or the messages age out under your retry configuration. A function that's marginal on timeout with a 100-record batch will often clear the same data comfortably at a batch size of 25, without ever touching the 14-minute limit. Shrinking the batch is frequently the actual fix, not lengthening the clock.
What Happens the Instant Lambda Times Out
It's worth knowing exactly what "timed out" means mechanically, because it changes how you write defensive code around it. When the configured duration elapses, Lambda halts the execution environment immediately. Your code does not get a graceful shutdown signal — no finally block runs, nothing is rolled back, and any side effect that had already happened (a database write, a payment API call) stays happened, even though the invocation as a whole is reported as a failure.
Billing follows the configured timeout, not the useful work done: a function that times out is billed for the full duration it was allowed to run, in 1-millisecond increments, not just the portion before it got stuck. Setting a generous timeout "just in case" on a function that consistently completes in 2 seconds costs nothing extra when it succeeds — but a function that regularly times out at 900 seconds is quietly billing 900 seconds every time it fails.
When 900 Seconds Genuinely Isn't Enough
Sometimes the task really does need longer than 15 minutes — a large batch export, a multi-step order pipeline waiting on a human approval, a workflow polling an external job for hours. That's not a Lambda timeout problem anymore; it's an architecture question, and there are now two legitimate answers.
🕐 What changed since this used to be a one-answer question
- Before: the only way past 15 minutes was AWS Step Functions, orchestrating a chain of separate Lambda invocations, each under the cap.
- Now: AWS Lambda durable functions, generally available since December 2025, let a single function checkpoint its own progress and suspend for up to a year, resuming without re-running completed work — currently available for Python 3.13/3.14 and Node.js 22/24, with region coverage expanding since launch.
- What this means for you: for a straightforward long wait inside otherwise simple logic, durable functions can now avoid the extra orchestration layer Step Functions used to require.
✅ Why Step Functions Standard is still the one to reach for first
For anything that touches money, inventory, or another non-idempotent action, Standard Step Functions workflows run their steps exactly once by default and keep a full, auditable execution history for up to a year — that audit trail is worth more than the simplicity of a single durable function once real business logic and compliance requirements are involved.
Ethan puts it more bluntly: "Durable functions are the right call when you've got one function that just needs to sleep and wake up. The second you've got five different services that all need to hand off to each other in order, reach for Step Functions instead — you'll want the execution history when something breaks at 3am." Jake isn't fully convinced it's worth the extra service: "Isn't that just more stuff to learn and pay for, though?" Ethan's answer is direct: "It's a state machine you didn't have to write yourself. That's cheap compared to debugging a homemade retry loop at midnight."
Can You Just Stop a Runaway Execution?
This comes up constantly once a function is stuck in a loop or hammering a downstream service it shouldn't be. Here's the honest limit: there is no API call that reaches into a currently-running standard Lambda invocation and stops it. What you can do is stop it from happening again.
- Set reserved concurrency to zero. This throttles all new invocations immediately — it will not stop an invocation already in progress, but nothing new starts.
- Disable the trigger or event source mapping. For a Kinesis, SQS, or MSK-fed function, disabling the mapping stops new batches from being pulled, though already-in-flight batches will still run to completion or timeout.
Jake pushes back on this one too: "So if something's stuck right now, actively burning through my account, there's really nothing I can click?" Ethan is blunt about it: "Nothing that stops the one already in flight — and honestly, it's the biggest usability gap in the whole service. You throttle the future and wait out the past." The one exception is a durable execution: AWS Lambda's newer StopDurableExecution API (and the matching sam remote execution stop CLI command) can terminate a running durable execution and move it to a stopped state that can't be resumed — because durable executions are checkpointed and tracked by Lambda in a way a plain 15-minute invocation isn't.
Setting the Timeout Right the First Time
Once the actual bottleneck is fixed, set the timeout with intention instead of guessing. Base it on your p99 duration — the slowest 1% of real requests — plus a buffer, not the average and not the maximum. If your p99 sits at 4.2 seconds, a timeout around 6 seconds gives real headroom without hiding a genuine regression behind a number nobody will notice for months.
🙋♂️ Jake's Reality Check
"A customer's trade-in check timed out mid-transaction last month and I had no idea if it actually went through or not. That's the part that scared me."
Ethan doesn't dodge it: "That's exactly the risk of setting timeouts too high on anything that writes data." A too-generous timeout doesn't just cost more — it means a stuck request can sit there for minutes before Lambda finally reports the failure, leaving you longer in that same uncertain state Jake described.
- What Is AWS Lambda? A Plain-English Guide to Serverless
Start here if the timeout error is the first Lambda problem you've ever hit, and the "serverless" concept itself still feels fuzzy.
Frequently Asked Questions
What is the default timeout for a new Lambda function?
Three seconds. Every newly created function starts here unless you set a different value at creation time through the console, CLI, or an infrastructure-as-code template.
What is the maximum timeout Lambda allows?
900 seconds, or 15 minutes, for a standard function invocation. This is a hard ceiling with no way to raise it further for a single invocation — event source mappings for MSK, Kafka, DocumentDB, and Amazon MQ cap it slightly lower, at 14 minutes.
Why does raising the timeout to 900 seconds sometimes not fix the error?
Because other layers in the request path — API Gateway's 29-second default, a Step Functions Express workflow's 5-minute cap, or an SQS visibility timeout — can cut the request off before Lambda's own configured timeout is ever reached.
Does the Lambda timeout include cold start time?
Yes. The clock covers the entire invocation, including Init Duration for a cold start, though CloudWatch reports Init Duration separately in the REPORT log line so you can tell how much of the total was startup versus your actual code.
What happens to my function the moment it hits its timeout?
Lambda halts the execution environment immediately. There's no graceful shutdown — no finally block runs, and any side effects that already occurred (a write, an API call) are not rolled back, even though the invocation is reported as failed.
Am I billed for the full timeout duration if the function fails partway through?
Yes. A function that times out is billed for its full configured duration, not just the work it completed before being stopped, measured in 1-millisecond increments.
Does Lambda retry a function after it times out?
It depends on how it was invoked. Asynchronous invocations may be retried automatically. Synchronous invocations, and event sources like SQS or MSK that use batches, generally return control to the caller or the queue/stream, which then decides whether to redeliver.
I raised the timeout in the console, so why is it still failing at 3 seconds?
Check whether you're editing the right function version or alias — an alias pointing to an older published version won't pick up a change made only to $LATEST. Also confirm the change actually saved; the console requires a separate Save click after editing the field.
Can API Gateway time out my request before Lambda's own timeout is reached?
Yes, and this is one of the most common causes of confusion. API Gateway's default integration timeout is 29 seconds, entirely independent of what you've set on the function. Since mid-2024 this can be raised beyond 29 seconds for Regional or private REST APIs, but it requires a separate service quota increase.
What is the maximum timeout for a Lambda function triggered by Amazon MSK?
14 minutes (840 seconds), not the usual 15. This applies to MSK, self-managed Apache Kafka, Amazon DocumentDB, and Amazon MQ event source mappings specifically.
How should I set my SQS queue's visibility timeout relative to the Lambda timeout?
At least six times the function's configured timeout, plus the value of MaximumBatchingWindowInSeconds. Lambda also requires the function timeout to be less than or equal to the queue's visibility timeout and will reject the event source mapping otherwise.
What's the difference between Step Functions Standard and Express workflows for long tasks?
Standard workflows run up to a year with exactly-once execution and a full audit history. Express workflows are capped at 5 minutes total, use an at-least-once model, and are billed differently — built for high-volume, short-duration processing rather than long or non-idempotent work.
Can a single Lambda invocation run longer than 15 minutes?
No, not as a standard invocation — 900 seconds is a fixed ceiling. To exceed it, either orchestrate multiple invocations with Step Functions, or use Lambda durable functions, which checkpoint progress and can suspend for up to a year across pauses that don't count against a single invocation's clock.
Can I manually stop a Lambda function that's stuck mid-execution?
Not a currently-running standard invocation — there's no API for that. You can set reserved concurrency to zero or disable the trigger to stop new invocations from starting. A running durable execution is the exception: it can be stopped directly through the StopDurableExecution API.
Should I just set every function's timeout to 900 seconds to be safe?
No. It hides genuine performance regressions, increases the cost of every failed invocation, and delays how quickly a stuck request is reported as failed. Base the timeout on your p99 duration plus a reasonable buffer instead.
How do I find out what's actually causing my function to time out?
Start with the CloudWatch REPORT line for the failed invocations to check Init Duration versus total duration, then use AWS X-Ray to trace which downstream call, if any, is slow. Compare p99 duration against your timeout rather than the average, since timeouts are almost always a tail-latency problem.
Revision note. Written September 2026, covering Lambda's current 3-second default and 900-second maximum, the 14-minute cap on MSK and Kafka event sources, API Gateway's 29-second integration timeout and the 2024 option to raise it, and Lambda durable functions since their December 2025 general availability. This page will need another pass once durable functions reach wider language and Region support. If a timeout error dragged you here at an inconvenient hour, hopefully the actual cause turned out to be something quick to fix.