6 de septiembre de 2026 · En JLPTest
El cron que decía «succeeded» mintiendo
La tarea diaria llevaba una semana en verde y sin publicar nada. La tabla que todo el mundo consulta no dice lo que parece decir.
Los tres productos hacen sus tareas periódicas dentro de Postgres, con pg_cron y pg_net: nada de un servidor de crones aparte que haya que vigilar y pagar. La tarea llama por HTTP a un endpoint del propio sitio, con un secreto en la cabecera.
Cuando la publicación diaria dejó de salir, lo primero fue mirar el historial del cron. Todo `succeeded`, un día tras otro. Y era verdad, sólo que no la verdad que uno busca: `net.http_post` es asíncrono y lo único que reporta es que la petición se encoló. Que la API contestara 500 es otra conversación, y está en otra tabla.
-- 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;La segunda trampa del mismo día: los crones corren en UTC. Un guardia de «una vez al día» que compare fechas en UTC se salta un día entero cuando tu zona va por detrás, y al revés publica dos veces. Todas las comparaciones de fecha se hacen ahora en la zona de México, explícitamente, aunque el servidor viva en otra.
Y la tercera, de seguridad: el secreto no va escrito en el comando del cron. `cron.job` guarda el comando entero y lo lee cualquiera que entre a la base, así que el secreto vive en Vault y el comando lo saca de ahí al vuelo.