Start free trial

Central data platform for your serverless environment.

Get full access to all premium features for 14 days. No code changes and no credit card required.

Password: 8+ characters, at least one upper case letter, one lower case letter, and one numeric digit

By signing up, you agree to our Privacy policy and
Terms and Conditions.

Debugging with Dashbird: Malformed Lambda Proxy Response


One problem that pops up quite frequently when people try to build serverless applications with AWS API Gateway and AWS Lambda is Execution failed due to configuration error: Malformed Lambda proxy response.

There is nothing worse than generic error messages that don’t tell you anything you need to fix the problem, right? And AWS isn’t particularly known for its error message design, if you can even call it that, let alone for giving you the means of fixing the problem. So how to fix this Lambda error and what causes it?

Fixing malformed Lambda proxy response

In order to fix this, you need to change what your Lambda function returns. And to do so, you need to return an object with two attributes:

  • statusCode – which is the HTTP status code you want to give your client with type number.
  • body – which is the content of your HTTP response with type string.

 If you used an asynchronous function, it should look like this:

exports.handler = async function(event, context) {
  return {statusCode: 200, body: "OK"};

If you’re more of a promise type of developer, it would look like this:

exports.handler = function(event, context) {
  return new Promise(function(resolove, reject) {
    resolve({statusCode: 200, body: "OK"});

And finally, if you’re into callbacks, this will resolve your problem:

exports.handler = function(event, context, callback) {
  callback({statusCode: 200, body: "OK"});

Understanding the Malformed Lambda proxy error response

If you have some time to spare, why not learn a bit about the “Why” of the error along the way?

First, Malformed Lambda proxy response isn’t really a configuration error because the problem lies in your Lambda code. But still, it could very well be that the routine that checks your return value also checks for other things that can be configured from the outside, like from AWS CloudFormation.

But what about the proxy part of that error message? 

If you configure a route for your API in AWS API Gateway in the AWS Console, you get to choose an integration for that route, in our case, a Lambda integration. This integration is the glue between AWS Lambda and AWS API Gateway. After all, Lambda can be used for more than just handling API Gateway requests.

If you configure the route via CloudFormation, things get a bit clearer. 

  Type: AWS::ApiGatewayV2::Route
      Ref: ExampleApi
    RouteKey: ANY /
        - integrations/
        - Ref: ProxyIntegration
  Type: AWS::ApiGatewayV2::Integration
      Ref: ExampleApi
    IntegrationType: AWS_PROXY
        - ExampleFunction
        - Arn
    PayloadFormatVersion: "2.0"
  Type: AWS::Lambda::Function
        'exports.handler = async () => ({ statusCode: 200, body: "Example" });'
    Handler: index.handler
        - ExampleRole
        - Arn
    Runtime: nodejs12.x
    - ExampleRole

I guess you already spotted the important point here. The integration we create in the AWS Console is actually a specific type of integration, called AWS_PROXY. It’s used to integrate with many AWS services and the AWS Console just has a nice UI to make integrating with Lambda simpler.

There are actually five types of API Gateway integrations. Three you can use for your WebSockets endpoints and two for the HTTP endpoints.

HTTP Integration Types

When you build a regular HTTP API.

  1. AWS_PROXY to integrate with Lambda, or other AWS services, like Step Functions.
  2. HTTP_PROXY to pass-through a request to another HTTP endpoint.

WebSocket Integration Types

When you build a WebSocket based HTTP API.

  1. AWS to integrate with Lambda.
  2. HTTP to integrate with other (i.e., third-party) HTTP APIs.
  3. MOCK to make a WebSocket endpoint work as a loop-back, without any other service involved.


Error messages are a common pain point for developers, but often the fix is quite simple. However, if you know a bit of background to the error’s origin, it can help to fix it faster in the future.

To learn more about specific common serverless errors and how to fix them, make sure to visit our Event Library.

Made by Developers for Developers

Our history and present are deeply rooted in building large-scale cloud applications on state-of-the-art technology. Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

10,000+ developers trust Dashbird

Dashbird helped us reduce the time to discovery from 2-4 hours to a matter of seconds. This means we’re saving dozens of hours in developer time, which not only can be funneled into improving the product but also means hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.

Read our blog

AWS Step Functions Input and Output Manipulation Handbook

In this handbook, you’ll learn how to manipulate AWS Step Functions Input and Output and filter this data.

How to Save Hundreds of Hours on Lambda Debugging

Learn simple ways to save a ton of time when scanning logs to debug errors in your Lambda functions.

Why Are Some Engineers Missing The Point of Serverless?

Why are some engineers missing the point of serverless? Let’s have a look at the common critique points, benefits, drawbacks of serverless, and if it makes sense for your use case.

How Dashbird innovates serverless monitoring

What makes an effective serverless monitoring strategy? In this article, we’re discussing the three core ideas that Dashbird’s serverless monitoring tool was built on top and that should be the fundamentals of any effective serverless monitoring approach.

Debugging with Dashbird: Malformed Lambda Proxy Response

A problem that pops up quite frequently when people try to build serverless applications with AWS API Gateway and AWS Lambda is: Execution failed due to configuration error: Malformed Lambda proxy response.Learn what causes it and how to fix it.

Go to blog