Cron Generator + Explainer

Cron schedules for alerts, searches and jobs

A standard cron expression has five space-separated fields — minute, hour, day of month, month, day of week — and the same five-field syntax drives Splunk scheduled searches and alerts and Kubernetes CronJobs. What differs between them is the clock the expression is evaluated against.

Field explanation

* means every allowed value. A slash creates an interval, so */15 means every 15 units. Hyphens define ranges and commas define lists; a range can carry a step, so 2-59/5 runs at minute 2, 7, 12 and so on.

Common examples

Splunk scheduled searches and alerts

Splunk accepts five-field cron for scheduled reports and alerts. In Splunk Enterprise the schedule is evaluated in the time zone the search head is configured with; in Splunk Cloud Platform it is always UTC. The same 0 2 * * * therefore runs at different absolute times on two deployments in different zones.

Many searches on the same */5 schedule all start in the same second and can overload the scheduler and indexers. Spread them by offsetting the minute field (1-59/5, 2-59/5, …) or with allow_skew in savedsearches.conf, which delays each start by a stable random amount while still searching the scheduled time range. The schedule window setting is a different feature, for searches that are being skipped.

Kubernetes CronJobs

Without .spec.timeZone, the schedule is interpreted in the local time zone of kube-controller-manager, which may not be the zone you assume. Set .spec.timeZone (stable since Kubernetes 1.27), for example Etc/UTC; CRON_TZ= or TZ= prefixes inside the schedule are rejected by validation.

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

A CronJob creates a Job approximately once per scheduled time; in some circumstances it can create two or none, so jobs should be idempotent. concurrencyPolicy defaults to Allow, which lets a slow run overlap the next one; Forbid skips the new run instead. If more than 100 schedules are missed, the controller stops starting the Job until startingDeadlineSeconds or clock skew is fixed.

Time zone pitfalls

Prefer UTC for schedules that feed alerting and reports, so daylight-saving changes and server relocations do not move them. When both day-of-month and day-of-week are restricted, traditional cron runs when either matches: 0 9 1 * 1 runs on the 1st of the month and on every Monday.

Sources

• Use cron expressions for alert scheduling — Splunk Enterprise documentation, 9.4
• Offset scheduled search start times — Splunk Enterprise documentation, 9.2
• CronJob — Kubernetes documentation

Last reviewed: October 2026