Run Jobs Every Six Hours at Minute Zero | CronBase
0 */6 * * * At the start of every sixth hour, running four times a day.
The `0 */6 * * *` cron expression schedules a task to run exactly every six hours, specifically at the top of the hour. This means the job triggers four times a day, at midnight, six in the morning, noon, and six in the evening.
- Minute
- 0
- Hour
- */6
- Day of Month
- *
- Month
- *
- Day of Week
- *
Next 5 Runs
- in 3h 20m
- in 9h 20m
- in 15h 20m
- in 21h 20m
- in 1d 3h
* Tools
Code & Implementations
#!/bin/bash
# Production deployment script to install a 6-hour maintenance cron job
set -euo pipefail
CRON_JOB="0 */6 * * * /usr/local/bin/backup-cleanup.sh >> /var/log/backup-cleanup.log 2>&1"
# Safely add the job to crontab without duplicating existing entries
(crontab -l 2>/dev/null | grep -Fv "/usr/local/bin/backup-cleanup.sh"; echo "$CRON_JOB") | crontab -
echo "Cron job successfully deployed to crontab." › Setup notes
Save this script as deploy_cron.sh, make it executable with chmod +x, and run it. It safely injects the 6-hour schedule into the current user's crontab while avoiding duplicate entries.
const cron = require('node-cron');
// Schedule a task to run every six hours (at minute 0)
cron.schedule('0 */6 * * *', () => {
try {
console.log(`[${new Date().toISOString()}] Starting 6-hour system diagnostics run.`);
// Implement your application-specific cleanup or sync logic here
} catch (error) {
console.error('Error executing 6-hour scheduled job:', error);
}
}, {
scheduled: true,
timezone: "Etc/UTC"
}); › Setup notes
Install the node-cron package using npm install node-cron. This script initializes a scheduler configured to run in UTC to prevent DST issues.
from apscheduler.schedulers.blocking import BlockingScheduler
import logging
import sys
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)
def perform_sync():
try:
logger.info("Starting 6-hour database synchronization routine.")
except Exception as e:
logger.error(f"Task failed: {e}", exc_info=True)
scheduler = BlockingScheduler()
# Trigger matches standard cron: 0 */6 * * *
scheduler.add_job(perform_sync, 'cron', hour='*/6', minute=0, timezone='UTC')
try:
logger.info("Scheduler started. Waiting for execution...")
scheduler.start()
except (KeyboardInterrupt, SystemExit):
logger.info("Scheduler stopped.")
sys.exit(0) › Setup notes
Install the apscheduler library using pip install apscheduler. Run this script to start a blocking scheduler that triggers the synchronization task every 6 hours in UTC.
package main
import (
"fmt"
"log"
"os"
"os/signal"
"syscall"
"github.com/robfig/cron/v3"
)
func main() {
// Use UTC timezone to avoid DST shift anomalies
c := cron.New(cron.WithLocation(cron.UTC))
_, err := c.AddFunc("0 */6 * * *", func() {
log.Println("Executing 6-hour API synchronization routine...")
})
if err != nil {
log.Fatalf("Error scheduling cron job: %v", err)
}
c.Start()
fmt.Println("Cron scheduler initialized. Press Ctrl+C to exit.")
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
<-sigChan
c.Stop()
log.Println("Scheduler stopped cleanly.")
} › Setup notes
Create a go.mod file, run go get github.com/robfig/cron/v3, and execute this main.go file. It runs a daemonized scheduler that handles system OS termination signals cleanly.
package com.example.cron;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import java.util.logging.Logger;
@Component
public class SixHourScheduler {
private static final Logger logger = Logger.getLogger(SixHourScheduler.class.getName());
// Spring's cron format includes seconds as the first field: "0 0 */6 * * *"
@Scheduled(cron = "0 0 */6 * * *", zone = "UTC")
public void executeTask() {
try {
logger.info("Starting scheduled 6-hour cache warming procedure.");
// Execute business logic here
} catch (Exception e) {
logger.severe("Cache warming execution failed: " + e.getMessage());
}
}
} › Setup notes
Ensure @EnableScheduling is declared on your main Spring Boot Application class. This component will automatically be picked up and executed every six hours in UTC.
apiVersion: batch/v1
kind: CronJob
metadata:
name: six-hour-cleanup-job
namespace: default
spec:
schedule: "0 */6 * * *"
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
jobTemplate:
spec:
template:
spec:
containers:
- name: cleanup-worker
image: alpine:latest
command: ["/bin/sh", "-c", "echo 'Cleaning database logs...'; sleep 10"]
restartPolicy: OnFailure › Setup notes
Apply this configuration using kubectl apply -f cronjob.yaml. The concurrencyPolicy is set to Forbid to prevent multiple jobs from running simultaneously if a previous execution hangs.
Last verified:
Keep this cron job monitored 24/7
UptimeRobot alerts you the moment a scheduled job stops responding. Free plan monitors up to 50 endpoints — no credit card required.
Platform Equivalents
AWS EventBridge
Standard cron expressions often need conversion for AWS EventBridge schedules.
cron(0 */6 * * ? *) Systemd Timer
OnCalendar*-*-* 00/6:00:00
[Unit]
Description=Timer for cron expression: 0 */6 * * *
[Timer]
OnCalendar=*-*-* 00/6:00:00
Persistent=true
[Install]
WantedBy=timers.target
Last verified:
Frequently Asked Questions
At what exact times does this cron schedule execute?
This schedule executes precisely at 12:00 AM, 6:00 AM, 12:00 PM, and 6:00 PM. The execution time is determined by the system clock of the server running the cron daemon.
How does Daylight Saving Time affect this six-hour interval?
During Daylight Saving Time (DST) changes, the interval may temporarily become 5 or 7 hours depending on whether the clock skips forward or falls back. To prevent this, configure your cron environment to use Coordinated Universal Time (UTC) instead of local time.
Can I offset the execution to avoid the top-of-the-hour peak?
Yes, you can shift the execution to run at a specific minute offset, such as fifteen minutes past the hour, by changing the first field. For example, using `15 */6 * * *` will run the job at 12:15, 6:15, 12:15, and 6:15.
What happens if a six-hour job takes longer than six hours to complete?
If a job execution exceeds six hours, a new instance will start while the previous one is still running. This can cause resource exhaustion or database lock contention. You should implement a locking mechanism, such as flock in Bash or a distributed lock manager, to prevent concurrent executions.
Is this schedule suitable for high-priority transaction backups?
While a six-hour interval is excellent for general backups, high-velocity transactional databases typically require a tighter recovery point objective (RPO). For critical financial or user data, a more frequent schedule like hourly or every fifteen minutes is highly recommended.
* Explore
Related expressions you might need
Last verified: