Run a Cron Job Every Minute
Cron expression to run a job every minute. Learn the syntax, see the next scheduled runs, and deploy it instantly with TrigRun.
Field-by-Field Breakdown
| Field | Value | Meaning |
|---|---|---|
| Minute | * | every minute |
| Hour | * | every hour |
| Day of Month | * | every day of month |
| Month | * | every month |
| Day of Week | * | every day of week |
* * * * * is the highest-frequency standard cron expression — 1,440 executions a day, one for every minute of every hour. It is what teams reach for when something needs to be checked, retried, or refreshed faster than a human notices. It is also the schedule most likely to cause overlap, log spam, and surprise bills, so treat the workload itself, not the expression, as the question to design around.
When teams reach for this schedule
External health and liveness checks
Hitting a customer-facing endpoint every minute gives ~99.93% time-resolution on outages and matches what most uptime-monitoring SLAs measure. The work per run is small (one HTTP request, parse status, fan out alerts) so the per-minute cadence stays cheap.
Queue and inbox polling when push isn't an option
Some upstreams (legacy SOAP APIs, IMAP mailboxes, third-party CSV drops) don't support webhooks. A one-minute poll is the practical floor before you tip into rate limits, and it keeps p95 lag under 60 seconds for downstream consumers.
Retry and reconciliation sweeps
Sweeping a `pending_retry` table every minute lets a fast worker catch transient failures before SLAs slip, while keeping the heavy work off the request path. Pair with a status column and `updated_at` watermark so the sweep stays idempotent.
What to watch for
- •If a single run can take longer than 60 seconds, the next tick fires while the previous one is still working. Use a job-level lock or single-flight pattern, or downshift to
*/5 * * * *. - •Per-minute jobs dominate execution-history dashboards. Aggregate or sample logs at write-time so you can still read the timeline a week later.
- •Most managed cron platforms (including TrigRun) bill per execution. 1,440 runs/day × 30 days = ~43k executions/month per job — budget for that, or use a long-running worker with internal scheduling instead.
- •True sub-minute cadence (every 10s, every 30s) is not expressible in standard 5-field cron. You need either a 6-field variant (Quartz, Spring) or a different scheduler entirely.
Next 5 Scheduled Runs
Computed in UTC. Use the generator to compare UTC with your browser-local time.
- 1Wed, Jun 3, 2026, 04:40 PM
- 2Wed, Jun 3, 2026, 04:41 PM
- 3Wed, Jun 3, 2026, 04:42 PM
- 4Wed, Jun 3, 2026, 04:43 PM
- 5Wed, Jun 3, 2026, 04:44 PM
Schedule this with TrigRun
Deploy this cron schedule in seconds. Automatic retries, encrypted secrets, full execution history, and native MCP support for AI agents.
Start Scheduling — Free* * * * *
Frequently Asked Questions
What is the cron expression for every minute?
The cron expression * * * * * runs a job every minute. All five fields are wildcards, meaning the job triggers on every minute of every hour of every day.
Is running a cron job every minute a good idea?
It depends on the workload. Health checks, queue polling, and lightweight API pings work well at one-minute intervals. Avoid it for expensive operations that could overlap.
How do I prevent overlap when runs take longer than a minute?
Use a database-level advisory lock, a Redis SETNX guard, or a single-flight pattern at the job entrypoint. TrigRun also supports per-job concurrency limits so a slow run blocks the next tick from starting instead of stacking.