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.

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.