Cron Expressions for AI Workflows: Schedule Prompts, Data Jobs, and Model Evaluations

Overview

A cron job is a scheduled command. A traditional cron expression contains five time fields followed by the command to execute:

minute hour day-of-month month day-of-week command

The five fields generally use these ranges:

Common operators make expressions more precise:

• Asterisk (*): every permitted value, such as every hour.
• Comma (,): a list of values, such as 1,15 for the first and fifteenth day.
• Hyphen (-): a range, such as 9-17 for business hours.
• Slash (/): an interval, such as */15 for every fifteen minutes.

For example, 15 2 * * * means “at 02:15 every day” in the scheduler's configured time zone. A cron expression is only one part of a dependable workflow. The command also needs the correct working directory, environment variables, credentials, permissions, logging, timeout behavior, and retry strategy.

Before building a schedule, define the job's purpose and its acceptable delay. A nightly report can usually tolerate a missed run followed by a manual retry. A document ingestion process may need idempotency, checkpointing, and an alert when new files remain unprocessed. For prompt evaluations, record the prompt version, model configuration, input set, and results so that scheduled runs remain comparable. Guidance on evaluation design is available in our prompt testing framework guide.

Checklist by scenario

Document ingestion and indexing

For a batch process that checks an upload location every hour, a starting expression is:

0 * * * * /usr/bin/python3 /opt/ai-jobs/ingest.py

Before using it, confirm that the script can identify already processed documents. Use stable document identifiers, an ingestion status, or a durable checkpoint rather than assuming a run always finishes. If the job updates a retrieval index, make the operation safe to repeat. For workflows involving retrieval-augmented generation, also verify chunking, metadata, and citation handling; see the RAG application development guide for related implementation considerations.

Prompt evaluations

A weekly evaluation might run at 03:30 on Monday:

30 3 * * 1 /usr/bin/python3 /opt/ai-jobs/run_evaluations.py

Keep the evaluation inputs versioned and write results to a location that includes the run date or commit identifier. Store failures separately from low-quality model outputs: an API timeout, malformed response, and failed quality assertion require different follow-up actions. If the workflow expects structured responses, validate the output before scoring it. The structured JSON output guide covers schema validation and retry patterns.

Report generation

To generate a report on weekdays at 08:00, one conventional expression is:

0 8 * * 1-5 /usr/bin/python3 /opt/ai-jobs/create_report.py

Decide whether “weekday” should mean Monday through Friday according to the scheduler, or whether holidays and organizational calendars must also be excluded. Traditional cron does not usually know about business holidays. If that distinction matters, let the script consult an approved calendar or use a scheduler with calendar-aware rules.

Backups and exports

A daily backup at 01:00 could use:

0 1 * * * /opt/ai-jobs/backup.sh

Do not treat a successful command exit as proof that a usable backup exists. Check that the expected files were created, record their size or checksum where appropriate, and test restoration periodically. Keep backup credentials outside the cron expression and avoid printing secrets in command output.

Model and service health checks

A frequent health check can run every ten minutes:

*/10 * * * * /usr/bin/python3 /opt/ai-jobs/health_check.py

Define what counts as unhealthy: connection failure, excessive latency, invalid response format, missing tool-call arguments, or a service returning an error. Add a cooldown or deduplication mechanism so that one outage does not create a separate alert for every scheduled run. For safe function execution and argument validation, consult the LLM tool calling tutorial.

What to double-check

Time zone and daylight-saving behavior

Many cron environments use the host's local time, while containers, cloud schedulers, and managed services may default to UTC. Write the intended time zone next to every production schedule and verify the platform's configuration. A job scheduled for 02:30 in a daylight-saving region may encounter a skipped local time in one seasonal transition and a repeated local time in another. If running twice would be harmful, make the job idempotent and use a run lock or unique execution key.

Syntax differences

Not every scheduler implements the same grammar. Some systems add a seconds field, support special expressions such as @daily, or interpret day-of-month and day-of-week combinations differently. A cron expression builder can help draft a schedule, but always compare the result with the documentation for the actual runtime. Test the expression in a non-production environment before relying on it.

Environment and paths

Cron often runs with a smaller environment than an interactive shell. Use absolute paths for interpreters, scripts, and important files. Load configuration explicitly, for example through a restricted environment file or the scheduler's secret mechanism. Confirm the job's user can read inputs, write outputs, access required networks, and create logs.

Concurrency, duration, and retries

If a job takes longer than its interval, two instances may overlap. This can duplicate API requests, corrupt output files, or consume more model capacity than expected. Add a lock, queue, or concurrency limit. Decide whether failed jobs should retry inside the script, through the scheduler, or through an external workflow system. Set timeouts for network and model calls rather than allowing a hung process to remain indefinitely.

Common mistakes

• Reading fields from left to right without testing: Break an expression into plain language and verify it with representative dates.
• Assuming “every five minutes” means five minutes after the previous completion: */5 runs on clock boundaries. It does not automatically wait five minutes after a job finishes.
• Ignoring output and errors: Redirect output to a reviewed log location or an observability system, with rotation and access controls.
• Embedding secrets in commands: Command lines and logs can be exposed to other users or monitoring systems.
• Using a fixed schedule for an irregular workload: If processing depends on file arrival, an event-driven trigger or queue may be more appropriate than polling.
• Allowing duplicate processing: Design ingestion, report, and evaluation jobs to tolerate retries and partial completion.
• Assuming a scheduler is an orchestration system: Cron starts commands, but it may not provide dependency management, distributed locks, durable history, or rich alerting. Use additional tooling when those capabilities are required.

For AI applications, also review the job's output quality rather than monitoring only process health. A script can exit successfully while producing empty summaries, invalid structured output, unsupported claims, or incomplete tool results. Reliability practices such as validation, bounded retries, and explicit failure states complement the schedule itself. See this reliability checklist for reducing hallucinations in LLM applications.

When to revisit

Revisit each cron schedule before seasonal planning cycles, after changing infrastructure, and whenever the workflow's inputs or outputs change. A practical review should happen when:

• the script moves to a new host, container, operating system, or scheduler;
• the model, prompt, evaluation set, API, or authentication method changes;
• the expected volume of documents or requests increases;
• the organization changes its operating time zone or maintenance window;
• daylight-saving rules affect the selected local time;
• a job has missed a run, overlapped with itself, or generated an unexpected result;
• logs, alerts, backups, or retention settings are changed.

Use this final checklist before publishing a schedule: write the expression in plain language; confirm the scheduler's field order and time zone; run the command manually as the target user; test a nearby execution time; verify logs and exit codes; check timeout and concurrency behavior; confirm secrets are handled safely; and document the expected output and recovery step. When a workflow grows beyond a small, independent command, compare cron with a queue, workflow orchestrator, or managed scheduler. The best schedule is not merely valid syntax—it is a documented, observable, repeatable part of the AI workflow.