September 6, 2026 · In JLPTest
The cron that said “succeeded” while lying
The daily job had been green for a week and had published nothing. The table everyone checks doesn't say what it looks like it says.
All three products run their periodic jobs inside Postgres, with pg_cron and pg_net: no separate cron server to babysit and pay for. The job calls one of the site's own endpoints over HTTP, with a secret in the header.
When the daily post stopped going out, the first thing to check was the cron history. All `succeeded`, day after day. And it was true, just not the truth you're looking for: `net.http_post` is asynchronous, and all it reports is that the request was queued. Whether the API answered 500 is a different conversation, in a different table.
-- Esto miente para lo que quieres saber:
select status, return_message from cron.job_run_details order by start_time desc;
-- Esto es lo que contestó de verdad:
select id, status_code, content from net._http_response order by id desc limit 5;The same day's second trap: crons run in UTC. A “once a day” guard comparing dates in UTC skips a whole day when your zone runs behind, and double-posts the other way. Every date comparison is now done explicitly in Mexico time, even though the server lives somewhere else.
And the third, a security one: the secret isn't written into the cron command. `cron.job` stores the whole command and anyone with database access can read it, so the secret lives in Vault and the command pulls it at run time.