Programaciones cron para alertas, búsquedas y jobs

Una expresión cron estándar tiene cinco campos separados por espacios (minuto, hora, día del mes, mes y día de la semana) y la misma sintaxis de cinco campos se usa en las búsquedas programadas y alertas de Splunk y en los CronJobs de Kubernetes. Lo que cambia entre ellos es el reloj contra el cual se evalúa la expresión.

*/15****minutohoradíamesdía de la semana

Explicación de los campos

* significa todos los valores permitidos. Una barra crea un intervalo, de modo que */15 significa cada 15 unidades. Los guiones definen rangos y las comas definen listas; un rango puede llevar un paso, así que 2-59/5 se ejecuta en los minutos 2, 7, 12 y así sucesivamente.

Ejemplos comunes

*/5 * * * *Cada 5 minutos, en :00, :05, :10; por ejemplo, una verificación de alerta

2-59/5 * * * *Cada 5 minutos, con un desfase de 2 minutos

0 * * * *Cada hora, en punto

15 2 * * *Todos los días a las 02:15; por ejemplo, un reporte o un job de limpieza

0 9 * * 1-5Días hábiles a las 09:00

0 9 1 * *El primer día de cada mes a las 09:00

Búsquedas programadas y alertas de Splunk

Splunk acepta cron de cinco campos para reportes y alertas programados. En Splunk Enterprise la programación se evalúa en la zona horaria con la que está configurado el search head; en Splunk Cloud Platform siempre es UTC. Por eso el mismo 0 2 * * * se ejecuta en momentos absolutos distintos en dos despliegues de zonas diferentes.

Muchas búsquedas con la misma programación */5 empiezan todas en el mismo segundo y pueden sobrecargar el scheduler y los indexers. Distribúyelas desfasando el campo de minutos (1-59/5, 2-59/5, …) o con allow_skew en savedsearches.conf, que retrasa cada inicio en una cantidad aleatoria estable y aun así busca en el rango de tiempo programado. El ajuste de ventana de programación (schedule window) es otra función, pensada para las búsquedas que se están omitiendo.

CronJobs de Kubernetes

Sin .spec.timeZone, la programación se interpreta en la zona horaria local de kube-controller-manager, que puede no ser la que supones. Define .spec.timeZone (estable desde Kubernetes 1.27), por ejemplo Etc/UTC; los prefijos CRON_TZ= o TZ= dentro de la programación son rechazados por la validación.

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "15 2 * * *"
  timeZone: "Etc/UTC"
  concurrencyPolicy: Forbid

Un CronJob crea un Job aproximadamente una vez por cada momento programado; en algunas circunstancias puede crear dos o ninguno, por lo que los jobs deben ser idempotentes. concurrencyPolicy es Allow por defecto, lo que permite que una ejecución lenta se solape con la siguiente; Forbid omite la nueva ejecución. Si se pierden más de 100 programaciones, el controlador deja de iniciar el Job hasta que se corrija startingDeadlineSeconds o el desfase del reloj.

Trampas con las zonas horarias

Prefiere UTC para las programaciones que alimentan alertas y reportes, de modo que los cambios por horario de verano y los traslados de servidores no las muevan. Cuando se restringen tanto el día del mes como el día de la semana, el cron tradicional se ejecuta cuando coincide cualquiera de los dos: 0 9 1 * 1 se ejecuta el día 1 del mes y todos los lunes.

Fuentes

Usa expresiones cron para programar alertas — documentación de Splunk Enterprise, 9.4
Desfasa los horarios de inicio de las búsquedas programadas — documentación de Splunk Enterprise, 9.2
CronJob — documentación de Kubernetes

Última revisión: octubre de 2026

Generador y explicador de cron