Programar un webhook

El costo de mantener su propio programador

Un equipo pequeño construyendo un producto SaaS, una persona desarrollando un proyecto personal, o un equipo de herramientas internas en una empresa más grande, todos terminan necesitando que algo suceda en un horario: un reporte nocturno, una revisión de renovaciones de suscripción, un precalentamiento de caché, y la respuesta tradicional es un proceso persistente en algún lugar: un demonio cron en una máquina virtual, un contenedor programado, una función sin servidor con su propia configuración de programación. Cada una de esas opciones necesita monitoreo, necesita sobrevivir reinicios, y necesita que alguien note cuando deja de dispararse en silencio. Para una sola tarea recurrente, esa infraestructura es desproporcionada frente al trabajo que hace.

Registrar un horario en una sola llamada

POST /dev/cron-webhook acepta una expresión cron y una URL de webhook destino, junto con el contenido a enviar en cada disparo; una vez registrado, el horario se guarda y el webhook se dispara automáticamente en cada momento correspondiente, sin sondeo ni conexión persistente de su lado. La solicitud de registro en sí se pone en cola de forma asíncrona y devuelve un task_id que confirma que el horario está activo, con confirmación entregada por webhook firmado o por un enlace firmado válido por 24 horas.

Una sintaxis cron que sobrevivió a las razones por las que se inventó

El formato de expresión cron se construyó para la utilidad cron original de Unix en los años setenta, para que los administradores listaran tareas recurrentes en una tabla de texto plano sin un programador gráfico. Décadas después, esa misma sintaxis compacta sigue siendo el lenguaje común para describir horarios recurrentes en casi cualquier plataforma, razón por la cual construir sobre ella, en vez de inventar una sintaxis de programación nueva, significa que las expresiones cron existentes, y el conocimiento de cómo escribirlas, se trasladan directamente a este endpoint.

Qué reemplaza en un sistema real

En vez de un proceso en segundo plano cuyo único trabajo es despertar, revisar la hora y disparar una solicitud HTTP, esa lógica se traslada por completo al registro del horario, y su aplicación solo necesita exponer un endpoint que reciba el webhook y haga el trabajo real cuando se le llame. Esto encaja de forma limpia con el resto de un flujo de tareas: un webhook disparado según un horario puede a su vez iniciar otras tareas asíncronas. A $0.002 por solicitud, el costo de mantener un disparador programado es insignificante frente a la infraestructura que reemplaza.

Acceso, confiabilidad y estado actual

Usar el endpoint requiere saldo prepago; sin saldo, la solicitud de registro devuelve HTTP 402 en vez de un horario que nunca se dispara en silencio. Una entrega fallida del disparo se reintenta automáticamente hasta tres veces antes de reportar un error claro, y un intento fallido nunca se cobra. El endpoint está activo ahora, y los datos del contenido asociados a cada horario se manejan bajo las mismas reglas de retención y borrado que el resto de la API, nunca se usan para entrenamiento.