Web APIs effectively signal failures using HTTP status codes, but batch jobs require a different approach for their execution environments to recognize an error. Initially, the author found an existing Lambda function that was intended to signal errors by returning false or a status: 500 object. However, from Lambda's perspective, these actions resulted in a successful invocation, preventing errors from being logged in CloudWatch. Consequently, a configured CloudWatch alarm failed to trigger, and no Slack notification was sent. The author realized that the familiar pattern of returning a 500 status code, common in web APIs, was not applicable to batch jobs. Instead, for a batch job, the entire invocation must fail for the execution environment to detect an issue. To resolve this, the error handling was refactored to throw an exception, which caused the Lambda invocation to truly fail. This failure was then correctly reflected in the CloudWatch Errors metric, enabling the alarm to trigger and the notification to be sent. The experience highlighted that error handling extends beyond the application code itself. It necessitates ensuring that failures are observable by external monitoring and alerting systems. Therefore, when considering error handling, one must ask not only how the error is managed internally but also how external systems will be made aware of the failure. This ensures that monitoring and alerting mechanisms function as intended for batch processes.