Run Daily at 9 PM | CronBase

cron expression Standard
$ 0 21 * * *

Once every day at 9 PM

0
Minute
21
Hour
*
Day of Month
*
Month
*
Day of Week

* In a Nutshell

The cron expression 0 21 * * * runs Once every day at 9 PM. This daily cadence is ideal for batch processing tasks that don't require sub-hourly execution. Scheduling for late evening minimizes impact on peak user activity, ensuring smooth data aggregation or report generation without performance degradation.

* When to use this

Use 0 21 * * * when a recurring task needs to run Once every day at 9 PM. This schedule is commonly associated with daily schedules and data sync and report generation workloads. It uses Standard (5-Field POSIX) syntax, supported by Unix cron daemons, cloud schedulers such as AWS EventBridge, and container orchestration platforms such as Kubernetes CronJob.

CronBase parses 0 21 * * * using a dialect-aware rules engine that identifies the Standard (5-Field POSIX) format, validates field structure against the Standard (5-Field POSIX) specification, and produces the translation above. Next run times are calculated by forward-scanning from the current UTC clock. Learn how CronBase works.

Platform Implementations

Bash

Prerequisites

Unix/Linux host with a cron daemon running (vixie-cron, cronie, or systemd-cron). The script at /usr/local/bin/run-task.sh must exist and be executable (chmod +x).

Configuration

Run crontab -e to open the crontab editor. Cron reads the server's local timezone; prefix with CRON_TZ=UTC before the expression to pin to UTC. Always redirect output with >> /var/log/cron-tasks.log 2>&1 to capture both stdout and stderr.

Gotchas

Cron jobs inherit a minimal PATH — use full binary paths or set PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin at the top of the crontab. For sub-hourly schedules, add flock -n /tmp/run-task.lock before the command to skip overlapping runs if the previous execution is still running.

bash
# Add to crontab with: crontab -e
0 21 * * * /usr/local/bin/run-task.sh >> /var/log/cron-tasks.log 2>&1

Last verified:

Nodejs

Prerequisites

Node.js 18+ with node-cron installed (npm install node-cron). Add "type": "module" to package.json to use the import syntax shown above.

Configuration

Pass { timezone: 'UTC' } as the third argument to cron.schedule(). Without this option the schedule uses the Node.js process timezone, which shifts during DST transitions when servers are not pinned to UTC.

Gotchas

node-cron uses standard 5-field cron syntax — not Quartz 6-field. If your job runs longer than the schedule interval the next trigger fires while the previous is still executing. Use a boolean guard or a queue to skip concurrent runs rather than relying on the scheduler to enforce it.

nodejs
import cron from 'node-cron';

cron.schedule('0 21 * * *', async () => {
  console.log('[cron] running at', new Date().toISOString());
  // your task logic here
}, { timezone: 'UTC' });

Last verified:

Python

Prerequisites

Python 3.8+ with apscheduler installed (pip install apscheduler). For Python 3.12+ use apscheduler>=3.10.

Configuration

CronTrigger.from_crontab() accepts a standard 5-field cron string. Always pass timezone='UTC' to both the BlockingScheduler constructor and the trigger to ensure consistent scheduling regardless of the server's locale.

Gotchas

BlockingScheduler.start() blocks the calling thread indefinitely. For a web application, use BackgroundScheduler instead and call scheduler.start() at application startup. APScheduler logs missed fires if the process is stopped and restarted — configure misfire_grace_time (in seconds) to control how late a missed job is allowed to run.

python
from apscheduler.schedulers.blocking import BlockingScheduler
from apscheduler.triggers.cron import CronTrigger

scheduler = BlockingScheduler(timezone='UTC')

@scheduler.scheduled_job(
    CronTrigger.from_crontab('0 21 * * *', timezone='UTC')
)
def run_task() -> None:
    print('task running')
    # your task logic here

scheduler.start()

Last verified:

Golang

Prerequisites

Go 1.18+ and github.com/robfig/cron/v3 (go get github.com/robfig/cron/v3).

Configuration

Always create the scheduler with cron.New(cron.WithLocation(time.UTC)). Without WithLocation, the library defaults to the server's local timezone. Call c.Start() to begin the scheduler, then block with select {} to keep the process alive.

Gotchas

robfig/cron v3 uses standard 5-field cron expressions by default. To add second-level precision (6 fields), pass cron.WithSeconds() to cron.New() — but this changes field positions, so never mix syntaxes in the same scheduler. Always check the error returned by c.AddFunc() — a malformed expression is silently ignored without it.

golang
package main

import (
	"fmt"
	"time"

	"github.com/robfig/cron/v3"
)

func main() {
	c := cron.New(cron.WithLocation(time.UTC))
	_, err := c.AddFunc("0 21 * * *", func() {
		fmt.Println("task running at", time.Now().UTC())
		// your task logic here
	})
	if err != nil {
		panic(err)
	}
	c.Start()
	defer c.Stop()
	select {}
}

Last verified:

Java

Prerequisites

Spring Boot 2.7+ (or Spring Framework 5.3+) with spring-context on the classpath. Annotate your @SpringBootApplication class with @EnableScheduling — without it, @Scheduled methods are silently ignored.

Configuration

Spring @Scheduled uses a 6-field Quartz-style expression: [sec] [min] [hr] [dom] [mon] [dow]. The expression 0 0 21 * * ? is derived from 0 21 * * * — a leading 0 is prepended for the seconds field, and ? replaces the unconstrained day field.

Gotchas

Standard Unix cron has 5 fields; Spring requires 6. Pasting a 5-field expression directly into @Scheduled shifts every field by one and the job misfires silently. Use ? for either dom or dow — Quartz does not allow both to be *.

java
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class ScheduledTask {

    @Scheduled(cron = "0 0 21 * * ?")
    public void runTask() {
        System.out.println("task running at: " + java.time.Instant.now());
        // your task logic here
    }
}

Last verified:

Kubernetes

Prerequisites

Kubernetes 1.21+ (CronJob API is GA). kubectl configured with cluster access. Container image must be pullable from within the cluster.

Configuration

Apply with kubectl apply -f cronjob.yaml. Check status with kubectl get cronjobs and inspect run history with kubectl get jobs. concurrencyPolicy: Allow is set because this schedule fires infrequently — parallel runs are acceptable.

Gotchas

Without startingDeadlineSeconds, a missed job (e.g., due to cluster downtime) triggers as soon as the controller recovers. Kubernetes 1.25+ supports timeZone: UTC in the spec to avoid timezone ambiguity. Keep successfulJobsHistoryLimit and failedJobsHistoryLimit low to avoid accumulating stale Job objects in the cluster.

kubernetes
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scheduled-task
spec:
  schedule: "0 21 * * *"
  concurrencyPolicy: Allow
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: task
            image: alpine:3.19
            command: ["/bin/sh", "-c", "echo 'task running'"]

Last verified:

AWS EventBridge Equivalent

Standard cron expressions often need conversion for AWS EventBridge schedules.

EventBridge Rule
cron(0 21 * * ? *)

Frequently Asked Questions

What does the `0 21 * * *` cron expression signify?

This cron expression is scheduled to execute once every day at precisely 9 PM, aligning with the end of a typical business day.

How does this schedule handle Daylight Saving Time clock changes?

Schedules operating on a fixed hour like this one will adjust automatically when Daylight Saving Time begins or ends, ensuring the job still runs at the intended local time each day.

How can I verify that my daily 9 PM job is running correctly?

You can verify the job's execution by checking its logs or output files, which should be generated shortly after 9 PM each day.

What potential issues should I be aware of with a daily schedule?

A critical consideration is ensuring the job completes before the next scheduled run. If a job takes longer than 24 hours, subsequent runs could be missed or overlap.

What is a common variation for this type of daily schedule?

A frequent variation involves running the task at a different time of day, such as midnight, to accommodate system maintenance or data archival needs.

More schedules like this

Explore Daily Schedules →

* Try any expression

Standard, Quartz, AWS EventBridge, Jenkins, named schedules (@daily, @hourly…)

* Keep Exploring

Related expressions you might need