Define a schedule with cron syntax or a visual builder, pick an IANA timezone, and Bahriya runs your container at the cadence you set. Every execution has its own logs, exit code, and per-minute cost — and you can trigger an ad-hoc run any time.
Bring any OCI-compliant image. Set a standard 5-field cron expression (*/15 * * * *, 0 9 * * 1-5) or use the visual builder for common patterns (every N minutes, daily at HH:MM, weekly on selected days, monthly on a day-of-month).
Pick any IANA timezone and your schedule fires in that timezone regardless of which region the cron job runs in. 09:00 in Asia/Karachi means 09:00 Karachi time even if the workload runs in Helsinki — no manual UTC conversion.
Every run appears in the Schedule & Runs tab on the cron job detail page. See start time, duration, status (Active / Succeeded / Failed), and exit code per execution. Click any run to stream the logs from that specific pod.
Trigger an ad-hoc execution from the console or the CLI — useful for debugging or running your batch out of cycle. Suspend a cron job to pause scheduling without deleting it; resume when you're ready. No new runs fire while suspended, and no compute is billed.
Platform features
Operational details that turn a schedule into something you can rely on in production.
Schedule
Choose a preset pattern in the visual builder or write raw cron syntax for full control. Toggle between the two without losing your expression. Live preview shows the human-readable description and the next five fire times in your selected timezone.
Concurrency
Choose Forbid (skip the next run if the previous is still going — the default and safest choice), Allow (run in parallel), or Replace (cancel the previous, start the new). One field, no surprises at 02:00.
Failure handling
Configure how many times a failed run retries before being marked Failed, and an optional active deadline that kills a run if it runs longer than expected. Failed runs are kept in history (configurable limit) for inspection.
Ad-hoc execution
Trigger a one-off execution from the console UI, the CLI (reis container:run), or the API. The on-demand run uses the same image, environment, and resources as a scheduled run and appears in the history the same way.
Lifecycle control
Pause a cron job to stop new runs while keeping the configuration intact. Useful during maintenance windows, incidents, or feature rollouts. Resume to bring the schedule back. No new compute is billed while suspended.
Billing
Billed per minute for the time your pod is actually running, 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 for 120. No charge between executions, no charge while suspended.
Use cases
The workloads that run on a clock instead of a request.
Aggregate yesterday's data, generate reports, recompute search indexes, refresh materialised views — anything you do once a day during low-traffic hours. Schedule it once, see exit codes for every run.
Purge stale sessions, rotate logs, delete temporary files, archive old records. Set a cadence that fits your retention policy. If a run fails the cron job retries up to your configured limit and surfaces the failure in the history.
Push data to a partner's SFTP every hour, sync to an analytics warehouse every fifteen minutes, hit a webhook every Monday morning. Cron jobs run alongside your other containers so they share secrets, project context, and observability.
Run VACUUM, snapshot a database, refresh a read replica, or ship backups to object storage. Cron jobs encapsulate the operational tasks that don't belong in your application's request path.
Deploy the same cron job to multiple regions and it fires independently in each. Per-execution history is tagged by region.
Choose how many successful and failed run records to keep per cron job — defaults are sensible, but you can tune them.
Optional starting deadline: skip a run if the cluster missed it by more than N seconds (instead of catching up an hour later).
Manage cron jobs through the console UI, the Reis CLI (container:run / suspend / resume / runs), or declarative YAML for GitOps.
Coming Soon
Planned for later in 2026/2027, timeline subject to change.
Persistent block storage that attaches to your containers. Retain data across restarts and deployments without external storage services.
Redis-compatible in-memory data store with persistent snapshots and restore. Session caching, queues, pub/sub, and real-time data — without Redis licensing concerns.
Managed relational database with automated backups, point-in-time recovery, and regional deployment. A production-ready RDBMS for structured data and transactional workloads.
Managed PostgreSQL with automated backups, point-in-time recovery, and regional deployment. Advanced SQL features, JSONB support, and extensions for modern application workloads.
A globally distributed, multi-region document database with built-in replication. Conflict-free sync across regions for offline-first applications and geo-distributed NoSQL workloads.
S3-compatible object storage for files, media, backups, and static assets. Accessible from your containers or directly via standard S3 APIs and client libraries.
Global content delivery network for static assets, media, and API acceleration. Edge caching across multiple PoPs with automatic origin pull from your containers or object storage.
Managed RabbitMQ for asynchronous messaging between containers. Multi-region clusters, project-private networking, and per-node billing — same operational model as Memcached.
Bring any container image, pick a cadence, and Bahriya handles the rest — including the run history, the logs, and the per-minute billing.
