No single cron expression runs exactly every 25 minutes: */25 * * * * fires at :00, :25 and :50, then restarts on the hour. See the real run times, and what to use instead.
*/25minute*hour*day*month*weekday*/25 isn't really every 25 minutes
The minute field restarts every hour, so after :50 the next run is :00 — a 10-minute gap, not 25. Even alternatives: */2, */3, */4, */5, */6, */10, */12, */15, */20, */30.
In Plain English
What your cron expression actually means.
Upcoming Executions
Preview the next 50 times this schedule will trigger.
About */25 * * * *
*/25 * * * * is the closest single line, but it isn't every 25 minutes. The minute field restarts every hour, so this fires at :00, :25 and :50 and then at :00 again — a 10-minute gap. No crontab can fix that: 25 divides neither an hour nor a day, so the pattern never lines up. If the exact interval matters, use a step that divides 60 (20 or 30), or run the job from a loop or a systemd timer with OnUnitActiveSec=25min.
Cron reads the five fields as minute hour day month weekday. For this schedule that breaks down as:
| Field | Position | Matches |
|---|---|---|
*/25 | minute | 0, 25, 50 |
* | hour | every hour |
* | day of month | every day |
* | month | every month |
* | day of week | every day of the week |
New to cron? Read the syntax reference or the FAQ.
Use it in crontab or GitHub Actions
The single line below is the closest cron gets, not the exact schedule (see above). A crontab runs in the server's local timezone; GitHub Actions always evaluates schedules in UTC. For Kubernetes, AWS EventBridge, or Vercel, use the export menu in the calculator above.
crontab
# At 0, 25, and 50 minutes past the hour, every hour, every day */25 * * * * /path/to/command
GitHub Actions workflow
# At 0, 25, and 50 minutes past the hour, every hour, every day
# Note: GitHub Actions always runs schedules in UTC.
on:
schedule:
- cron: '*/25 * * * *'