Lambda debugging and traceability demo

This demo shows a happy path and two negative paths against a Java AWS Lambda behind API Gateway. It is designed to make request IDs, trace IDs, validation errors, and stack traces easy to inspect so prospects can see how debugging and incident investigation work in practice.

This demo was designed and built through a human-led process, with AI used to assist with wording, presentation polish, and code refinement.

Problem and solution

Problem

API failures are often hard to debug once requests leave the browser.

Dev teams need to understand whether an issue came from validation, an upstream API error, or an internal server failure, and they need clear request IDs and trace IDs to investigate it quickly.

Solution

This demo simulates success and failure scenarios in a controlled way.

It shows a happy path, a validation error, and an internal error so teams can see how logging, stack traces, and response handling help explain what happened.

Why it matters

API failures are often hard to debug once requests leave the browser.

Frequency API incidents are common across modern systems.

OWASP treats API logging and monitoring failures as one of the most critical API security risks.

Severity Poor observability slows root-cause analysis.

Without clear request IDs, trace IDs, and failure states, validation errors and server failures can look the same.

Business impact Detection delays increase operational and financial damage.

OWASP notes that insufficient logging and monitoring can let attackers operate unnoticed long enough to fully compromise systems.

Sources: OWASP API Security Top 10, OWASP A09:2021, Secure APIs: Observability for API security

Run the demo

The Lambda accepts a single query parameter named userInput. Use 13 to force an internal error, a non-number to trigger a validation error, or a normal number for the success path.
Endpoint: https://ymakbkchng.execute-api.us-east-1.amazonaws.com/Demo/process?userInput=VALUE

What this demonstrates

Happy path
200 response with message, processed input, request ID, and trace ID.
Validation error
400 response when input is missing, empty, invalid, or out of range.
Forced failure
500 response when input equals 13 and the function throws an internal exception.
Traceability
Every response includes requestId and traceId for CloudWatch and X-Ray correlation.

Last response

Waiting 
Run the demo to see the API response here.

Debug notes

The response pane will show the raw JSON returned by Lambda. For failures, the page highlights the message, error type, request ID, and trace ID so it is easy to map the browser action back to CloudWatch logs and X-Ray traces.
Suggested talking point: the lambda intentionally logs the same payload structure it returns, making it easy to correlate user actions, API responses, log events, and trace data.