AWS Lambda Cold Start Timeout Fix When Function Hangs

Quick Fix: Bump the Timeout to 30 Seconds (30 seconds)

Don't waste time looking at code yet. The culprit here is almost always the default 3-second timeout. AWS Lambda's default timeout is 3 seconds — that's way too short for cold starts, especially when you're using Java, Python with heavy libraries, or anything connecting to a database.

Here's what you do:

1. Open the Lambda function in the AWS Console
2. Go to General Configuration → Edit
3. Set Timeout to 30 seconds (or 1 minute if you're feeling cautious)
4. Save and test

If that fixes it, you're done. Most people stop here. The function will still cold start slowly, but at least it won't timeout on you. If you're still seeing timeouts, move to the next step.

Why this works: Cold starts can take 5-10 seconds for Java or Node.js with large dependencies. The default 3 seconds just isn't enough. Bumping it to 30 gives your code room to breathe during initialization.

Moderate Fix: Add Provisioned Concurrency (5 minutes)

If bumping the timeout didn't cut it — or you're tired of slow cold starts — you need Provisioned Concurrency. This keeps a set number of Lambda instances warm and ready to go. No cold start at all.

Here's the setup:

1. In your Lambda function's console, go to Configuration → Provisioned Concurrency
2. Click Add Provisioned Concurrency
3. Set the Concurrency count to a number that matches your expected traffic. Start with 5 if you're unsure.
4. Pick the Alias or Version you want to apply it to (usually your production alias)
5. Save — it'll take a couple minutes to warm up the instances

Cost warning: This costs money. You pay for the warm instances even when nobody's calling them. For low-traffic functions, it's usually cheaper to just live with the 3-second cold start. But if you're seeing timeouts under load, it's worth it.

Set up Provisioned Concurrency for your most critical functions — like API endpoints that need sub-second responses. Don't use it for batch processing or cron jobs.

One gotcha: Provisioned Concurrency only works on published versions or aliases. You can't use it on the $LATEST version directly. Create a version first, then point your alias to it.

---

Advanced Fix: Use SnapStart for Java Lambdas (15+ minutes)

If you're stuck with Java and you've tried everything else, Lambda SnapStart is your last resort. It's a game-changer for Java cold starts — cuts them from 5-10 seconds down to under 1 second. But it comes with caveats.

Here's how to enable it:

1. Go to your Lambda function in the AWS Console
2. Under General Configuration, click Edit
3. Find SnapStart and set it to Enabled
4. Save and publish a new version

What SnapStart actually does: When you enable it, AWS takes a snapshot of your function's memory and CPU state after initialization (right after the handlers are loaded). On subsequent cold starts, it restores that snapshot instead of running init code. It's basically a VM snapshot restore.

But watch out for these issues:

• No unique data in init: If your initialization code generates random values, database connections, or reads from files, those get frozen in the snapshot. Every cold start will reuse the same connection or random seed. That's bad for things like UUID generation or session tokens.
• No ephemeral state: Don't put anything in memory that changes between invocations. SnapStart restores the exact same state every time.
• Java only: This doesn't work for Node.js, Python, or Go. Just Java 11 and newer (Corretto).

If you're running a Spring Boot app on Lambda, SnapStart is your best bet. The startup time for Spring Boot alone can be 10-15 seconds, and SnapStart eliminates most of that.

Troubleshooting SnapStart: If your function fails after enabling SnapStart, look at the Init phase logs in CloudWatch. You'll see a Restore phase that replaces Init. If the restore fails, your code is probably doing something stateful during init.

One more thing — if you're not on Java, skip SnapStart entirely. Your options are: bump timeout (quick fix), or Provisioned Concurrency (moderate fix). There's no magic bullet for Python or Node cold starts.

Pro tip: For Node.js and Python, check your code for heavy require or import statements. Lazy-load dependencies that aren't needed on every invocation. That alone can shave 2-3 seconds off cold starts without spending any money.

If you've tried all three steps and still see timeouts, you've got a deeper issue — probably a bug in your handler code that's hanging on every invocation, not just cold starts. Check CloudWatch logs for the exact line where the function hangs. Good luck.