Cron jobs vs webhooks: ¿por horario o por evento?

Toda automatización arranca con la misma decisión de arquitectura, aunque nadie la nombre: ¿esto corre por reloj o por disparo? La diferencia entre cron jobs y webhooks es quién inicia la acción: un cron job ejecuta una tarea según un horario programado ("todos los días a las 7:00"), mientras que un webhook se dispara cuando ocurre un evento ("apenas entra un pago"). El cron conviene para tareas periódicas donde la inmediatez no importa; el webhook, para todo lo que necesita reacción en segundos. Elegir mal no rompe nada de entrada — pero te cuesta plata y velocidad todos los días.

Qué es un cron job, con ejemplos de negocio

Un cron job es una instrucción al servidor: "ejecutá este programa en este horario". El nombre viene de cron, el programador de tareas histórico de los sistemas Unix, donde una línea como 0 7 * * 1 significa "lunes a las 7:00".

Casos donde el cron es la respuesta natural:

• Reporte comercial diario: a las 7:00, consultar las ventas de ayer, armar la planilla y mandarla al equipo.
• Backups: todas las noches a las 3:00, respaldar la base de datos.
• Conciliación: una vez por día, cruzar cobros del banco contra facturas emitidas.
• Recordatorios de vencimiento: cada mañana, buscar facturas que vencen en 3 días y disparar el aviso.
• Limpieza: cada domingo, archivar registros viejos para que el sistema no engorde.

El patrón común: son tareas periódicas por naturaleza. No existe "el evento" que las dispare — el disparador es el calendario.

Qué es un webhook, con ejemplos de negocio

Un webhook invierte la lógica: en lugar de que tu sistema pregunte, el otro sistema avisa. Le registrás una URL tuya a Mercado Pago, a tu e-commerce o a tu plataforma de WhatsApp, y cuando ocurre el evento, ese sistema le pega a tu URL con los datos en el momento. Lo explicamos pieza por pieza en qué es un webhook y para qué sirve.

Casos donde el webhook es la respuesta natural:

• Confirmación de pago: el cliente paga y en menos de un segundo tu sistema libera el pedido. Hacerlo por cron cada hora significa clientes esperando hasta 59 minutos.
• Venta en el e-commerce: entra la orden → se descuenta stock → se notifica a depósito. Todo encadenado al instante.
• Mensaje de WhatsApp entrante: el bot tiene que responder en segundos, no "en la próxima pasada".
• Lead del formulario web: cada minuto de demora en el primer contacto baja la tasa de conversión; acá la latencia es plata.

Cron jobs vs webhooks: la tabla que resuelve la decisión

Criterio	Cron job	Webhook
Quién inicia	Tu servidor, por calendario	El sistema externo, por evento
Latencia	Desde minutos hasta 24 hs (según frecuencia)	Menos de 1 segundo, típicamente
Costo de cómputo	Corre aunque no haya nada que hacer	Solo consume cuando hay evento
Complejidad de implementar	Baja: un script y una línea de cron	Media: necesitás un endpoint público, validación y manejo de reintentos
Confiabilidad de entrega	Alta: si el servidor está vivo, corre	Buena, pero un webhook puede perderse (red, caída momentánea)
Requiere que el otro sistema colabore	No	Sí: debe ofrecer webhooks
Caso típico	Reporte diario, backup, conciliación	Pago confirmado, mensaje entrante, orden nueva

Regla rápida: si llegar 15 minutos tarde no cambia el resultado, usá cron. Si cada minuto de demora cuesta una venta o un cliente irritado, necesitás webhook.

¿Tu operación reacciona a los eventos o se entera "en la próxima corrida"? Agendá 30 minutos con nuestro equipo y revisamos qué procesos tuyos están perdiendo plata por latencia.

El error clásico: polling cada minuto

El antipatrón más común que encontramos en empresas que automatizaron "a pulmón": usar un cron como webhook de los pobres. Como el sistema externo "no avisa" (o nadie configuró que avise), alguien programa un cron que pregunta cada minuto: ¿hay pagos nuevos? ¿hay pagos nuevos? ¿hay pagos nuevos?

Eso se llama polling, y los números lo condenan solos:

• Un polling por minuto = 43.200 consultas por mes a la API del otro sistema.
• Si tenés 200 eventos reales por mes, el 99,5% de esas llamadas vuelven vacías.
• Las APIs tienen límites de uso (rate limits): el polling agresivo los consume, y en el peor caso el proveedor te bloquea o te degrada el servicio — justo el día de más ventas.
• Y con todo ese gasto, tu peor latencia sigue siendo de 59 segundos. Pagaste caro para seguir llegando tarde.

Si el sistema ofrece webhooks, usalos. Si no los ofrece, el polling es aceptable como excepción — pero con frecuencia razonable (cada 10-15 minutos para datos no urgentes) y con consultas inteligentes que pidan "solo lo nuevo desde la última vez", no todo el historial en cada pasada.

La arquitectura profesional: combinarlos

Los sistemas serios no eligen uno: usan los dos, cada uno en su rol.

1. Webhooks como vía principal: cada evento llega y se procesa al instante.
2. Cron de reconciliación como red de seguridad: cada hora (o cada noche), una tarea programada le pregunta al sistema externo "¿qué eventos hubo?" y los cruza contra lo que recibiste. Si un webhook se perdió — pasa: una caída de 30 segundos de tu servidor alcanza — el cron lo detecta y lo repone.

Sin esa red, los webhooks perdidos generan el peor tipo de error: el silencioso. Un pago que entró pero nunca liberó el pedido, y nadie se enteró hasta el reclamo del cliente. Este patrón webhook-más-reconciliación es estándar en las integraciones por API que desarrollamos, y es una de las diferencias entre una automatización de demo y una de producción.

Un segundo patrón híbrido útil: el webhook encola, el cron procesa. Si recibís picos de eventos (una liquidación masiva, un día de promoción), el webhook solo anota el evento en una cola, y un proceso programado los trabaja en orden sin saturar tus sistemas internos.

Cuándo NO complicarte con webhooks

La honestidad técnica primero: los webhooks tienen costo de entrada y no siempre se justifica.

• Si la tarea es genuinamente periódica (reporte, backup, conciliación), forzar eventos es sobreingeniería. El cron de toda la vida es más simple, más fácil de debuggear y más barato.
• Si no tenés infraestructura para recibirlos: un webhook necesita un endpoint público, con HTTPS, validación de firma (cualquiera puede pegarle a una URL pública — tenés que verificar que el aviso sea legítimo) y manejo de reintentos. Si tu automatización vive en una notebook de la oficina, no tenés dónde recibirlo.
• Si el volumen es mínimo y la urgencia también: para 10 eventos por día sin apuro, un polling cada 15 minutos es una solución perfectamente digna.

Y la limitación inversa del cron: no le pidas inmediatez. Subir la frecuencia "para que reaccione rápido" es el camino directo al antipatrón del polling.

Decidilo con esta pregunta

Para cada proceso que quieras automatizar, preguntate: ¿el valor está en el momento o en la constancia? Pago confirmado, mensaje entrante, orden nueva → momento → webhook. Reporte, backup, conciliación, recordatorio → constancia → cron. ¿Las dos cosas? → webhook con cron de respaldo.

Esta decisión es una de tantas que definen si una automatización aguanta producción o se cae a los tres meses — el panorama completo lo armamos en qué es la automatización programática. En Deepyze diseñamos e implementamos estas arquitecturas para empresas de toda LATAM, desde integraciones por evento hasta plataformas de automatización con IA y software a medida donde crons y webhooks conviven bien diseñados. Precio fijo cerrado antes de arrancar, propuesta en 24 horas y un equipo en tu mismo huso horario. Contanos qué proceso necesitás que reaccione más rápido y lo arquitecturamos juntos.