What makes a job “complete” without delivering

• Platform not configured in the processYou enable the channel in the config, but the delivering process was already running and read the old config. The job finishes with “platform not configured” and a success status.
• Manual run ≠ scheduled runRunning the job by hand uses a different delivery path than the scheduler's. The manual test is green and the scheduled one never delivers.
• Output file instead of the channelThe job writes the text to a file instead of talking to the channel's API. It looks like delivery; it is a log.
• Token in the wrong placeThe credential exists in your shell's environment, not in the scheduler's — and the error shows up as “no permission”, not “no token”.

The proof that does not lie

There is exactly one proof of delivery: the identifier the channel returned when it accepted the message. Store it and show it in the job report.

Job status, exit code and a “success” log are all compatible with the message never leaving. The id is not.

How to actually test it

1. Force the delivery conditionA job that “has nothing to do” tests nothing. Run it once with guaranteed content.
2. Read the result from the channel's sideConfirm on the channel (or via its API) that the message arrived — not in the scheduler's log.
3. Log which path was used“Run by the scheduler” and “run by hand” must appear in the log: without that, you are testing the wrong path.

If the job is silent when there is nothing to do

Silence by design needs proof that the job ran: one log line per execution. Without it, “I received nothing” and “the job did not run” are indistinguishable — and you find out weeks later.

See the complete pack See all skills

Want this wired into your project? Guided setup from R$ 1.500, with the first cycle run together.