How to Debug Serverless Functions

Are you trying to fix something you can’t see or touch? That’s what debugging serverless functions feels like. Your code runs somewhere in the cloud, finishes its job, then disappears. 

No server to check, no logs sitting around waiting for you. When something breaks, you’re left scratching your head, wondering what went wrong.

Here’s the thing.

Serverless functions are great. They run when you need them, stop when you don’t, and you only pay for what you use. By 2026, around 50% of global enterprises will have adopted serverless computing, which shows how popular this approach has become. 

But there’s a catch. 

When errors pop up, finding them feels like searching for a needle in a haystack. The function already ran and vanished. How do you figure out what happened?

Serverless functions bring unique problems.

• They time out unexpectedly, run out of memory, or fail to connect to databases. 
• Sometimes they just freeze, and you have no idea why. 
• Plus, your code might touch five different services in a single request, making it even harder to spot where things went wrong.

Ready to make debugging less painful? Let’s jump right in.

Step 1: Set Up Smart Logging

Logging is your best friend when debugging serverless functions. It’s the trail of breadcrumbs that shows what your code did before it disappeared. But here’s the thing.

Random print statements won’t cut it. You need organized, searchable logs that tell a clear story.

Log in JSON format. 

When you write logs as plain text, such as “User logged in” or “Payment processed,” they’re hard to search later. Instead, structure your logs as JSON. This makes them easy to filter and analyze.

Here’s what good logging looks like:

console.log(JSON.stringify({

level: ‘INFO’,

timestamp: Date.now(),

message: ‘Processing payment’,

userId: ‘12345’,

amount: 99.99,

paymentMethod: ‘credit card.’

}));

Now you can search for all logs with level: ‘ERROR’ or find everything for a specific user. Much easier than digging through random text.

Add correlation IDs. 

When one request triggers multiple functions, you need to connect all those dots. A correlation ID is like a tracking number that follows the request everywhere it goes.

If a user clicks “checkout” and that triggers five different functions, they all log the same correlation ID. Later, when something breaks, you can search for that ID and see the complete journey through your system.

Log the important moments. 

You don’t need to log every tiny step. That creates noise and costs money. Focus on:

• When your function starts (with input data)
• Before calling external services
• After getting responses back
• Any errors or weird situations
• When your function finishes (with results)

Use log levels wisely. 

Not all information is equally important:

• DEBUG: Detailed info for development
• INFO: Normal operations
• WARN: Something odd but not broken
• ERROR: Things that went wrong

In development, log everything. In production, stick to INFO and above. You can always turn on DEBUG temporarily when hunting a specific bug.

Watch your costs. 

Every log entry costs money. By 2023, over 70% of AWS customers were using at least one serverless technology, and many learned this lesson the hard way. Logging too much can rack up charges fast. So, balance detail with cost.

One developer I know logged every single database query in production. Their bill jumped $500 in one month just from logs. They didn’t need all that detail. A few key checkpoints would have been enough.

Keep it simple: log what you need to debug problems, not every tiny action your code takes.

Step 2: Track Requests Across Services

Your serverless function probably doesn’t work on its own. It talks to databases, calls APIs, and triggers other functions. When something breaks, you need to see the whole chain of events. That’s where distributed tracing comes in.

Distributed tracing is like having a GPS tracker for your requests. It shows you everywhere your request went, how long each step took, and where problems happened.

Turn on AWS X-Ray. 

If you’re using AWS Lambda, X-Ray is built right in. It automatically tracks requests as they move through different services. You just need to enable it:

First, give your function permission to write traces. Add AWSXRayDaemonWriteAccess to your function’s role. Then turn on “Active tracing” in your Lambda settings. That’s it—X-Ray starts recording.

See the service map. 

Once X-Ray is running, you will see a visual map of all your connected services. It looks like a flowchart. You can see your Lambda calling DynamoDB, which in turn triggers another Lambda that calls an external API. Each connection shows how long it took.

This is super helpful when you’re hunting down slow requests. Your function may run fast, but it’s waiting forever for the database. The service map shows that immediately.

Trace individual requests. 

When something goes wrong, X-Ray lets you drill into one specific request. You see every step: API Gateway received the request (10ms), Lambda started (500ms cold start), a database query ran (200ms), and an external API was called (2000ms—aha! that’s the bottleneck).

Use for other clouds too. 

Google Cloud has Cloud Trace. Azure has Application Insights. They all do the same job—track requests across services. Pick the one that matches your cloud provider.

Here’s a real example.

A company’s checkout function randomly failed. The logs showed errors but didn’t explain why. They turned on X-Ray and discovered their payment API sometimes took 31 seconds to respond. Their Lambda timeout was 30 seconds. Mystery solved. They increased the timeout and added retry logic.

Without distributed tracing, they would’ve been guessing. With it, they spotted the problem in five minutes.

Connect with correlation IDs. 

Remember those IDs from your logs? Distributed tracing uses them too. When you look at a trace in X-Ray, you can see the correlation ID. You can then search your logs for that same ID to get even more details.

Between structured logs and distributed tracing, you’ve got a complete picture of what your function did and how long everything took. These two tools together catch about 80% of serverless debugging problems.

Step 3: Use Cloud Monitoring Tools

Logs show you what happened. Tracing shows you where requests went. Monitoring tools show you patterns over time. They’re like the health dashboard for your serverless functions.

CloudWatch is your starting point. 

If you’re on AWS, CloudWatch automatically collects metrics. No setup needed. It tracks:

• How many times your function ran
• How many errors occurred
• How long functions took
• How much memory they used

Check these metrics when something seems off. If errors spike at 3 AM every night, CloudWatch shows you. If your function suddenly takes twice as long to run, you’ll see it in the duration graph.

Create custom metrics. 

The built-in metrics are great, but you can add your own as well. Track business stuff that clouds about:

• How many orders processed
• Average payment amount
• Failed login attempts
• Items added to cart

Custom metrics help you spot problems before they become disasters. If successful orders suddenly drop by 50%, something broke, even if no errors show up.

Set up alarms. 

Don’t wait for users to complain. Let CloudWatch tell you when things go wrong. Create alarms for:

• Error rate above 1%
• Function duration over 5 seconds
• No invocations in the last hour (for functions that should run regularly)

When an alarm triggers, CloudWatch sends you an email or Slack message. Fix problems before they affect many users.

Build a dashboard. 

Clicking through different screens to check metrics gets old fast. Build one dashboard that shows everything important. Put your error rates, invocations, durations, and custom metrics all in one place.

Every morning, glance at your dashboard. Everything green? Great. Something red? Time to investigate.

Consider third-party tools. 

CloudWatch is good, but specialized tools are better. AWS Lambda is used by 96% of serverless developers, and many use monitoring tools like:

• Datadog: Shows cold starts, tracks performance across AWS services
• New Relic: Gives recommendations for improving performance
• Lumigo: Explicitly built for serverless, super easy to use

These tools cost money but save time. They automatically catch problems CloudWatch might miss. For serious applications, they’re worth it.

Here’s what happened to a startup I worked with.

Their free tier ran out one night, and their functions started failing. They had no alarms set up. Users couldn’t sign up for four hours before someone noticed. One alarm checking error rates would’ve woken them up immediately.

Don’t let that be you. Set up monitoring and alarms before problems hit.

Step 4: Test Locally First

Deploying to the cloud every time you change one line of code is slow and frustrating. Test on your own computer first. It’s faster and easier to debug.

AWS SAM CLI runs functions locally. 

SAM stands for Serverless Application Model. It’s a free tool from AWS that simulates Lambda on your laptop. You write your code, test it locally, fix bugs, then deploy. Way faster than the deploy-test-fail-fix cycle.

Install it once:

brew install aws-sam-cli

Then run your function locally:

sam local invoke MyFunction -e test-event.json

Your function runs just like in the cloud, but on your machine. You see the output immediately. Errors? Fix them and run again. No waiting for cloud deployments.

Set up debugging in VS Code. 

SAM works with debugging tools. You can set breakpoints (spots where code pauses), step through your code line by line, and inspect variables. This is how you’d debug any regular program.

When your function hits a breakpoint, everything stops. You can see what’s in each variable, check if values are what you expect, and figure out exactly where things go wrong.

Test with realistic data. 

Your local tests need to match real situations. Save a copy of the actual events that trigger your function. Use those for testing. If your function processes orders, grab a real order object and test with that.

Know the limits. 

Local testing can’t perfectly match the cloud. Your function might work locally but fail in production because:

• Cloud permissions are different
• Your local database doesn’t match production
• Network connectivity works differently
• Cold starts don’t happen locally

So test locally to catch obvious bugs, but always test in the cloud before going to production. Use a staging environment that closely matches production.

Think of local testing as your first line of defense. It catches simple bugs fast. Then cloud testing catches the tricky issues that only happen in real environments.

Step 5: Debug in the Cloud

Sometimes you need to debug the actual cloud environment. Since July 2025, AWS offers remote debugging. You can debug Lambda functions running in the cloud directly from VS Code.

How remote debugging works. 

Install the AWS Toolkit extension in VS Code. Connect it to your AWS account. Select your Lambda function. Click “Debug.” That’s it.

Your function runs in the cloud with full access to VPC resources and databases, and to permissions. But you can set breakpoints and inspect variables just as you do in local debugging. Best of both worlds.

Why does this help?

Some bugs only happen in production. Your function can’t connect to the database because of the VPC settings. Or an IAM role is missing a permission. Testing locally won’t catch these. You need the real environment.

With remote debugging, you see exactly what’s happening in production without guessing. You can pause the function mid-execution and inspect everything.

Use it carefully. 

Don’t debug production functions while users are actively using them. Debug in staging first, or do it during low-traffic times. Pausing a function at a breakpoint means it’s not doing its job.

Also, remote debugging sessions time out. You can’t leave a function paused for hours. Get in, find the problem, fix it, done.

Step 6: Fix Common Errors Fast

Most serverless problems fall into a few categories. Once you’ve seen them, they’re easy to spot and fix.

Timeout errors. 

Your function takes too long and gets killed. Check your timeout setting in the Lambda configuration. Default is often 3-6 seconds. For functions that call external APIs or perform heavy processing, bump it up to 30 seconds or more. 

Just don’t make it too high. If something’s wrong, you don’t want functions running forever.

API Gateway has its own 30-second limit. If your function needs longer, use asynchronous processing instead.

Memory errors. 

Function crashes with “out of memory” errors. Check CloudWatch to see how much memory your function used. If it’s hitting the limit, increase the memory allocation. More memory also gives you more CPU power, so your function runs faster and costs less overall.

Permission errors. 

These show up in logs as “Access Denied” or similar. Your function needs permission to access other AWS services. Check your IAM role. If your function reads from S3, the role needs s3:GetObject permission. If it writes to DynamoDB, it needs the dynamodb:PutItem permission.

Missing permissions are super common. AWS is picky about security. If you didn’t explicitly grant access, you don’t have it.

Cold start delays. 

The first invocation takes 2-5 seconds, and subsequent ones are fast. That’s a cold start. You can’t eliminate them, but you can reduce their impact:

• Use lighter dependencies
• Choose faster runtimes (Python and Node.js are faster than Java)
• Increase memory allocation
• For critical functions, use Provisioned Concurrency (keeps instances warm)

Connection pool exhaustion. 

Your function can’t connect to the database. Serverless functions scale up fast. Suddenly, you have 100 instances trying to connect to a database that only allows 50 connections. 

Either increase your database connection limit or use connection pooling (RDS Proxy helps with this).

Environment variables wrong. 

Your function can’t find config values. Check the environment variables in the Lambda console. Make sure they match what your code expects. Typos in variable names cause hours of frustration.

One time, I spent three hours debugging why a function couldn’t find an API key. Turned out I named the variable API_KEY in code, but APIKEY in Lambda config. Silly mistake, easy fix once I found it.

Step 7: Catch Problems Before Users Do

The best bugs are the ones you find before users report them. Set up alerts and monitoring to catch issues early.

Track error rates. 

Normal applications have some errors; maybe 0.1% of requests fail. That’s fine. But if your error rate suddenly jumps to 5%, something’s wrong. Set an alarm to notify you when errors cross your threshold.

Monitor function duration. 

If your function takes 200ms normally but suddenly takes 2 seconds, investigate. Slow functions hurt user experience and cost more. CloudWatch can track duration percentiles. p50 (median), p99 (slowest 1%), etc.

Check for throttling. 

AWS limits how many functions can run at once. If you hit that limit, new invocations get throttled (rejected). This is bad. Set alarms for throttling events to increase your limit or reduce the number of concurrent executions.

Watch your bill. 

Runaway functions can cost a fortune. Set budget alerts to notify you if spending spikes suddenly. A function stuck in an error loop, retrying forever, can burn through hundreds of dollars overnight.

Use dead letter queues. 

When asynchronous functions fail repeatedly, AWS can send the failed events to a dead-letter queue. This is like a safety net. You can process these failed events later, fix the bug, then replay them. Without this, failed events just disappear.

Test in staging first. 

Never deploy directly to production. Use a staging environment that mirrors production. Test there first. Catch bugs where they don’t affect real users.

Step 8: Learn from Each Problem

Every bug you fix teaches you something. Write it down.

Keep a debugging log. 

When you solve a problem, document what went wrong and how you fixed it. Next time something similar happens (and it will), you’ll solve it in five minutes instead of five hours.

Make a simple document with:

• What broke
• How you found it
• What fixed it
• How to prevent it next time

Share knowledge with your team. 

Maybe someone else has hit the same problem. If you’ve documented it, they can fix it fast. Build a team playbook of common issues and solutions.

Review incidents.

When something breaks in production, have a quick meeting afterward. What happened? Why? How do we prevent it? No blame, just learning.

Now that you know how to debug serverless functions, what are some of the tools you can use to make the process easy?

Tools That Make Debugging Easier

You don’t need fancy tools to debug serverless functions, but some make life much easier.

For AWS:

• CloudWatch: Built-in metrics and logs
• X-Ray: Distributed tracing
• SAM CLI: Local testing
• AWS Toolkit for VS Code: Remote debugging

Third-party platforms:

• Datadog: Excellent serverless monitoring, shows cold starts clearly
• New Relic: AI-powered insights help find patterns
• Lumigo: Simple interface, built for serverless
• Sentry: Great error tracking

Which to choose? 

Start with CloudWatch. It’s free and automatic. 

As your application grows, add a third-party tool. Datadog and Lumigo are popular because they’re designed specifically for serverless.

If you get stuck debugging your serverless functions, that’s totally normal. Here is why.

Why Serverless Functions Are Tricky to Debug

Regular servers stick around. You can log in, check files, and see what’s running. 

Serverless functions don’t work that way. 

They start, do their job, then disappear. It’s like trying to fix a car that only exists while it’s driving.

Here’s what makes debugging harder:

They don’t stick around. 

Your function runs for a few seconds or minutes, then it’s gone. You can’t pause it or look inside while it’s working. Once it finishes, all the temporary data vanishes. If you didn’t save logs before it disappeared, you’ve got nothing to work with.

You can’t see the server. 

With traditional applications, you can check CPU usage, look at running processes, or read system logs. Serverless platforms hide all that from you. AWS, Google Cloud, or Azure handles everything behind the scenes. You write code, they run it, but you don’t get to peek under the hood.

Multiple pieces talk to each other. 

One user action might trigger your function, which then calls a database, sends a message to another function, and contacts an outside API. When something breaks, which piece caused it? The answer isn’t always obvious.

Cold starts confuse things. 

When your function hasn’t run for a while, the cloud provider needs to set everything up from scratch. This first run takes longer than usual. Sometimes way longer. If your function times out during a cold start, is it a code problem or just a slow startup? Hard to tell.

Errors hide in different places. 

One error might show up in your function logs. Another might only appear in your database logs. A third could be buried in API Gateway metrics. You need to check multiple spots to get the full picture.

Think of it this way.

Debugging a regular application is like fixing a machine in your garage. You can see it, touch it, and take it apart. Debugging serverless functions is like trying to fix a machine that’s sealed in a box, runs for thirty seconds, then melts away. You only get whatever information you managed to capture while it was running.

That’s why having the right tools and approach is so important. You need to plan ahead and set up ways to catch information before your function vanishes.

Final Tips

Start simple. Don’t try to implement everything at once. Begin with basic logging. Add tracing when you need it. Expand monitoring over time.

Test assumptions. When debugging, we often assume we know what’s wrong. Test your assumptions. Check the actual data, don’t guess.

Read error messages carefully. They usually tell you exactly what’s wrong. “Cannot read property ‘id’ of undefined” means something is undefined that shouldn’t be. Find what and fix it.

Check the basics first. Is the function running at all? Are environment variables set? Does it have the right permissions? Simple stuff catches a lot of bugs.

Use version control. If something worked yesterday and broke today, what changed? Git history shows you. You could revert the change and start over.

Ask for help. Stuck? Ask someone. Fresh eyes spot things you missed. The serverless computing market is expected to grow from $26.51 billion in 2025 to $76.91 billion by 2030, indicating a large community. Post in forums, check Stack Overflow, ask colleagues.

The Bottom Line

Debugging serverless functions is different from debugging regular applications. Functions vanish after running. You can’t poke around on a server. You need to capture information before it disappears.

The key steps are:

1. Set up structured logging with JSON and correlation IDs
2. Enable distributed tracing to track requests across services
3. Use CloudWatch or other monitoring tools to spot patterns
4. Test locally with SAM CLI before deploying
5. Use remote debugging for production issues
6. Fix common errors like timeouts and permissions
7. Set up alerts to catch problems early
8. Learn from each bug and document solutions

Start with basics: good logs and CloudWatch monitoring. That solves most problems. Add more advanced tools as you need them.

The serverless market continues to grow because the benefits outweigh the challenges. Yes, debugging is harder. But once you set up the right tools and processes, it becomes manageable. You’ll spend less time fighting infrastructure and more time building features.

Here is the thing: every expert was once a beginner who got stuck on the same problems you’re facing now. With practice, you’ll spot issues faster and fix them quicker. The first few bugs are hard. 

After that, it gets easier.