A batch job that returns false on failure makes your CloudWatch alarm decorative

The mismatch here runs one way only. Lambda decides whether an invocation counted as an error, and it decides on the basis of whether the handler threw or returned a value ^[5]. Whatever sits inside that returned payload is opaque to the decision, including the digits 500 ^[5]. The application had a vocabulary for failure that its own runtime does not read.

Then count what inherits that verdict. The Errors metric is derived from the invocation status ^[6], the alarm is derived from Errors, and the Slack message is derived from the alarm ^[7]. Three consumers downstream of one classification the code never set ^[1]. None of them malfunctioned. Each faithfully reported what the layer above it said, and the layer above it said the job ran fine.

Worth noting which part looked correct on inspection. The author reports the AWS-side configuration was not particularly complicated ^[3], and that is the trap: the wiring you can verify by reading it was the wiring that was already right. The defect was in the one place a monitoring change does not normally ask you to look.

The habit that produced it is transfer from HTTP work, where the status code is the channel and a client is on the other end of it ^[1]. A scheduled job has no such client ^[10]. The only party asking whether the run succeeded is the execution environment, and the only question it knows how to ask is whether the process terminated in a way it recognises as failure ^[1]. Replacing the returns with a thrown Error answered that question, which put the invocation into the Errors metric and gave the alarm something to fire on ^[8].

This is why code review does not catch it. An error log, a returned false, and a returned object containing 500 all read as error handling if you only look at the application ^[11]. All three are also invisible to the runtime. The reviewable property is not "does this function handle the error" but the one the author ends up at: who needs to observe this failure, and how will they find out ^[9].

The operational consequence is about test method. A monitoring pipeline that has never carried a real failure has not been tested, it has been assembled. Building the CloudWatch alarm and the Slack integration correctly ^[3] produced silence, and silence is exactly what the same pipeline emits when everything is healthy. The only way to tell those two states apart is to break the job on purpose and see whether the message arrives. Anyone who has ever inherited a green dashboard on a job that stopped working months ago is looking at some version of this: a failure the code handled, and nobody outside the code ever heard about ^[9].