Cron Jobs
Cron jobs run your container on a schedule. The container starts, runs to completion, and exits. Bahriya keeps a history of past runs and shows you the exit code and logs for each one.
Use cron jobs for:
- Nightly batch processing
- Periodic clean-ups (purging stale data, rotating files)
- Scheduled exports or report generation
- Database backups
- Any workload that runs at a fixed cadence and finishes
How it differs from HTTP Containers and Workers
- HTTP containers run continuously and serve HTTP traffic.
- Workers run continuously without any HTTP exposure.
- Cron jobs are scheduled and ephemeral — they only exist while a run is executing.
Required configuration
| Field | Description |
|---|
| Name | A human-readable label. |
| Handle | A unique lowercase identifier — immutable after creation. |
| Image | The full container image reference including tag. |
| Schedule | A cron expression (e.g. 0 9 * * 1 for every Monday at 09:00). The console has a visual builder if you don't want to write cron syntax. |
| Timezone | An IANA timezone (e.g. Europe/London, Asia/Karachi). The schedule fires in this timezone regardless of which region the cron job runs in. |
| Min CPU / memory | Guaranteed resources for the pod that runs your container. |
| Regions | One or more regions to run in. |
The schedule
A schedule is a standard 5-field cron expression — minute hour day-of-month month day-of-week. You can also use shortcuts like @hourly, @daily, @weekly, @monthly.
The console includes a visual builder for common patterns:
- Every N minutes or hours
- Daily at a specific time
- Weekly on selected days at a specific time
- Monthly on a specific day-of-month at a specific time
- Custom (raw cron expression)
The builder shows you a human-readable description and the next five fire times in your selected timezone.
Timezones
Cron jobs are timezone-aware. If you set the timezone to Asia/Karachi and the schedule to 0 9 * * *, the job fires at 09:00 Karachi time every day — wherever the cron job is running.
Concurrency policy
If a previous run is still executing when the next one is scheduled, the concurrency policy decides what happens:
- Forbid (default) — skip the new run, let the previous one finish.
- Allow — start the new run in parallel with the previous.
- Replace — cancel the previous run and start the new one.
Run history
Every execution appears in the Schedule & Runs tab on the cron job detail page. For each run you see:
- Start time and duration
- Status (Active, Succeeded, Failed)
- Exit code
- A link to the logs for that specific run
Bahriya keeps the last few runs per status — three successful and three failed by default, configurable per cron job.
Run now
You can trigger an ad-hoc execution at any time from the console, the admin console, or with reis container:run <id>. The on-demand run uses the same image, environment, and resources as a scheduled run and appears in the Run History the same way.
Suspend and resume
Suspending a cron job pauses scheduling without deleting it. No new runs fire while suspended. Resume the cron job to bring the schedule back. You can suspend or resume from the console, the admin console, or with reis container:suspend <id> / reis container:resume <id>.
Limits per run
Three optional limits you can configure for each run:
- Backoff limit — how many times to retry a failed run before giving up.
- Active deadline — kill a run if it exceeds this wall-clock time.
- TTL after finished — how long to keep the pod around after the run finishes (so logs remain inspectable).
Logs
The Schedule & Runs tab streams logs from a specific run when you click into it. You can also use reis container:run-logs <id> <jobName> --follow from the CLI.
Billing
Bahriya bills cron jobs per minute. Every execution is rounded up to the next whole minute with a 60-second minimum:
- A 5-second run is billed for 60 seconds.
- A 65-second run is billed for 120 seconds.
- A 3-minute run is billed for 180 seconds.
There is no charge while a cron job is suspended or between executions — suspend a cron job and billing stops immediately. The per-CPU-minute and per-MB-minute rates are the same as long-running HTTP and worker containers.
