Lambda Test succeeded, but Response says failure: Read logs and Duration separately

Lambda's console says Test succeeded, but the Response contains { "ok": false }. Those statements answer different questions. The invocation may have finished without a runtime error while the function deliberately returned a failed business result. Keep one test event fixed and read execution status, Response, Function Logs, and Duration separately.

What does a successful Lambda Test establish?

The diagram separates normal invocation completion from the value the function returns. The log shows the path taken; Duration shows execution time, not whether the order was valid.

The console Test invokes a function with a saved JSON event. Successful execution means the handler returned without an uncaught error or timeout; it does not certify that the returned business value is acceptable. AWS's console testing guide describes supplying an event and inspecting the result.

Consider this self-contained Node.js handler with a required order ID. It calls no database or external API:

export const handler = async (event) => {
  const orderId = event.orderId;
  console.log("received orderId:", orderId ?? "(missing)");

  if (typeof orderId !== "string" || !orderId.trim()) {
    return { ok: false, error: "orderId is required" };
  }

  return { ok: true, orderId };
};

With {} as the event, the handler returns ok: false; it does not throw. The invocation can therefore succeed. With { "orderId": "A-17" }, the same code returns ok: true. The Test status alone cannot tell you which result was returned.

Why do Response and Function Logs differ?

The return value is the response to the caller. For {}, it is:

{ "ok": false, "error": "orderId is required" }

console.log instead records what happened during execution. The same call logs received orderId: (missing). The following values describe this handler's behavior as checked in Node.js, not measurements captured from a live AWS console; the display format may vary by runtime and configuration.

This handler intentionally represents a missing field as a returned value. Throwing an error or hitting a timeout changes the invocation result. API Gateway and other event sources also interpret failure values differently; do not assume { ok: false } universally becomes an HTTP error or triggers a retry.

Does a short Duration mean the job succeeded?

No. Duration is a clue about execution time for that invocation. A missing orderId can produce a very quick ok: false. Read the execution status, then the Response's business value, the Function Logs' path, and finally Duration and memory information.

One or two console tests do not establish average production latency or cost. Input size, initialization, external waits, and memory settings can change the timing.

What if CloudWatch logs do not appear?

First make sure you are checking the same function and invocation. The console Test's short log view and CloudWatch Logs groups and streams are different places. Allow for delivery delay. If logs remain absent, inspect the function's execution role and log destination: permissions are needed to create log resources and put log events. AWS's Lambda logging guide covers the required permissions and default log-group naming.

If logs appear but Response differs from expectations, inspect the exact event JSON and the handler branch before blaming permissions. Avoid logging a full event or secrets merely to debug it; even an order ID may be sensitive in a real system.

Key takeaways

Lambda Test's success indicator describes invocation completion, not business success. Read the returned Response, execution logs, and Duration as separate evidence for the same event. If logs are missing, check the invocation and display location, allow for delivery delay, then verify the execution role's logging permissions.