# Cron Jobs — Managed Scheduled Tasks on Runsite

> Schedule background jobs on Runsite: Docker containers triggered by cron expressions, timezone support, concurrency policies, execution history and failure alerts.

1. [Home](/)
2. [Services](/services)
3. Cron Jobs

Coming soon

Cron Jobs aren't live yet — we're finishing the runtime and the dashboard. Sign up and we'll ping you the moment it ships.

Compute EU · Germany

# Managed Cron Jobs & Scheduled Tasks

Run scheduled tasks automatically. Set a schedule, we run your code — with logs and retries built in.

[Start with €5 credit](https://dashboard.runsite.app/login)[Read the docs](https://docs.runsite.app)

CPU

Up to 2 vCPU

Memory

Up to 512 MB

Timeout

Up to 1 hour

runsite — schedules

 3 jobs

 runsite cron ls

 0 3 * * *     pg-backup       ok · 41s

 */15 * * * *  sync-inventory  ok · 2.4s

 0 9 * * 1     weekly-digest   ok · 12s

 next run 03:00 CET

 retries 3 · overlap skip · history 30d 

Jobs are provisioned and executed in Germany

Overview

Runsite Cron Jobs runs scheduled tasks as containers, so backups, report generation, data syncs, and cleanup jobs happen without a server to babysit. Write a standard Unix cron expression, point it at a Docker image, and Runsite takes care of provisioning, timeouts, retries, and logging.

Jobs execute on infrastructure inside the European Union, so whatever data they read or write stays within EU borders. A signed GDPR Data Processing Agreement is included on every plan.

Every run is recorded with its exit code, output, and duration, and a failed run can alert you by email or webhook. Concurrency policies decide what happens when a run overlaps the previous one, so long jobs never pile up. Most jobs sit alongside the rest of your stack: dump a [PostgreSQL](/services/postgresql) backup to [object storage](/services/s3-storage), or refresh caches and data for your [web services](/services/web-services).

Last reviewed: September 2026

At a glance

CPU

Up to 2 vCPU

Memory

Up to 512 MB

Timeout

Up to 1 hour

Min Interval

Every minute

History

30 days

Concurrency

Configurable

Hosted in the EU · Germany

[Start with €5 credit](https://dashboard.runsite.app/login)

Features

## Everything to Run Scheduled Jobs

Built-in tools and capabilities to deploy and manage with confidence.

### Cron Schedule Syntax

Use standard Unix cron expressions to define when your jobs run — every minute, hourly, daily, weekly, or any custom interval.

Standard five-field Unix expressions, so the schedules you already have transfer unchanged. The scheduler lives outside your application, which is the difference that matters: an in-process timer only fires while that process is running, and a container that has been scaled to zero fires nothing.

### Timezone Support

Schedule jobs in any timezone. Run reports at 9 AM local time or batch processes at midnight in your users' timezone.

Schedules are evaluated in the timezone you pick rather than in UTC, which matters for anything tied to a working day. Note that daylight saving makes one local hour happen twice a year and one not at all, so a job at 02:30 needs an idempotent body.

### Concurrency Policies

Choose Allow, Forbid, or Replace policies to control what happens when a new run is triggered while a previous one is still executing.

Allow starts the new run regardless, Forbid skips it while the previous one is still going, and Replace stops the old one first. The default worth thinking about is Forbid: it is what keeps a job that has begun to run long from stacking copies of itself until memory runs out.

### Custom Docker Images

Run any script or binary in a Docker container. Bring your own image or use Runsite's built-in runtime images for popular languages.

Any image runs, so a job can be a shell script, a management command, or a compiled binary with no runtime around it. Using the same image as your web service means the job sees the same dependencies and the same code, which removes a whole class of drift.

### Execution History

Track every execution with status, duration, and logs. Set retention limits for successful and failed job history.

Every run records its exit code, its output and its duration, so a job that has been failing silently for a week is visible rather than inferred. Retention is configurable separately for successful and failed runs, since the failures are the ones worth keeping.

### Failure Alerts

Get notified when a job fails or exceeds its timeout. Configure retry behavior and alert channels for critical tasks.

A non-zero exit or a timeout raises an alert by email or webhook. This is the part a crontab on your own server does not do: there, a failed run writes to a log nobody reads, and the first sign of trouble is the report that never arrived.

Execution Lifecycle

## Schedule, run, monitor

Every scheduled job follows a predictable lifecycle with built-in safety nets for failures.

1

### Schedule Defined

Set a cron expression (e.g. 0 2 \* \* \* for daily at 2 AM) with a timezone. Choose a concurrency policy: Allow, Forbid, or Replace.

2

### Container Provisioned

At the scheduled time, Runsite spins up a fresh container from your Docker image with your environment variables and secrets injected.

3

### Execution & Timeout Guard

Your script runs inside the container. If it exceeds the timeout limit, the container is terminated and the run is marked as failed with an alert sent.

4

### Logs & History Recorded

Exit code, stdout/stderr output, duration, and resource usage are recorded. Failed runs trigger configurable alerts via email or webhook.

Code

## Get Started in Minutes

Simple integration with your existing tools and workflows.

daily-backup.sh

```
# Schedule: 0 2 * * * (daily at 2 AM)
# Timeout: 3600s

#!/bin/bash
pg_dump $DATABASE_URL | gzip > backup.sql.gz
aws s3 cp backup.sql.gz s3://backups/$(date +%F).sql.gz
```

Use Cases

## What You Can Automate

Common scenarios where this service shines.

### Database Maintenance

Schedule backups, cleanup old records, run data migrations, and generate reports on a recurring basis.

### Email Digests

Send daily or weekly digest emails, notification summaries, and scheduled marketing campaigns.

### Data Sync

Synchronize data between services, pull from external APIs, update caches, and refresh materialized views.

### Analytics & Reports

Generate daily analytics snapshots, compute aggregated metrics, and export reports to external systems.

EU-Sovereign

## Your Jobs Run Inside the EU

Hosted in Germany — your data stays under EU jurisdiction.

Scheduled containers are provisioned and executed in Runsite's German region. Any database rows, files, or API responses your job touches are processed inside the EU, and execution logs are stored there too.

Every account is GDPR-compliant by default and includes a signed Data Processing Agreement at no extra cost and with no sales call. You can review how we handle data in our [Privacy Policy and DPA terms](/privacy). That makes Runsite a fit when you handle EU customer data or fall under the GDPR or the EU Digital Services Act.

EU data residencyGDPR-readySigned DPA on every plan

Planned pricing

## Simple, transparent pricing

This service is still in development. The plans below are a preview — final pricing will be confirmed at launch.

Runsite is in Public Beta

Every service listed here is live, and paid plans bill exactly as shown. Beta means the platform is young. Features still change, and parts of the roadmap are not built yet.

### Starter

€3/mo

* 5 cron jobs
* Per-minute scheduling
* Failure alerts
* 14-day history
[Join the waitlist](https://dashboard.runsite.app/login)

### Pro

€12/mo

* Unlimited cron jobs
* Custom Docker images
* Extended timeout (1 hour)
* 30-day history
[Join the waitlist](https://dashboard.runsite.app/login)

### Every plan, side by side

__Cron Jobs plans and what each includes__
| Plan    | Price  | What it includes                                                                     |
| ------- | ------ | ------------------------------------------------------------------------------------ |
| Starter | €3/mo  | 5 cron jobs. Per-minute scheduling. Failure alerts. 14-day history                   |
| Pro     | €12/mo | Unlimited cron jobs. Custom Docker images. Extended timeout (1 hour). 30-day history |

[Compare all plans](/pricing)[Try the calculator](/pricing/calculator)

FAQ

## Frequently Asked Questions

Common questions about this service.

### What is the maximum execution time for a cron job?

The default timeout is 3600 seconds (1 hour). On the Business plan, you can request extended timeouts for long-running batch processes. If a job exceeds its timeout, it is terminated and marked as failed.

### What happens if a job is still running when the next execution is scheduled?

You can configure a concurrency policy: Allow (run in parallel), Forbid (skip the new run), or Replace (cancel the running job and start a new one). The default policy is Forbid.

### Can I run a cron job manually?

Yes. You can trigger any cron job manually from the dashboard at any time, regardless of its schedule. This is useful for testing or running one-off executions.

### How are cron job failures handled?

Failed jobs are logged with their exit code and output. You can configure alert notifications via email or webhook. The execution history shows all past runs with their status, duration, and logs for debugging.

Guides

## Learn More About Cron Jobs

Hands-on articles from the Runsite blog.

[Databases7 min readHow to Automate PostgreSQL Backups to S3 on a ScheduleA managed database backs itself up daily — but a second, portable copy in your own S3 bucket is yours to keep. Here's how to schedule pg\_dump to object storage with a cron job, and when it's worth doing.Read](/blog/postgresql-backup-to-s3)[Databases10 min readPoint-in-Time Recovery: How WAL Archiving Saves You After a DROP TABLEYour nightly backup answers "do we have a copy?" Point-in-time recovery answers "can we go back to 3:06pm?" Here's what the write-ahead log stores, how PITR replays it, and what it still can't undo.Read](/blog/postgres-point-in-time-recovery)[Deployment7 min readWhat Are Cold Starts — and Why Your Free-Tier App Keeps Falling AsleepCold starts make the first request to a sleeping app painfully slow. Here's why free hosting tiers spin down, what it costs you, and how to keep an app warm without paying for idle capacity.Read](/blog/cold-starts)

Related

## You Might Also Need

Services that work great together.

[Web ServicesNode.js, Python, Go, Ruby, Rust, or your own Dockerfile — Runsite builds it, runs it, and keeps it online on European infrastructure.Learn more](/services/web-services)[PostgreSQLManaged PostgreSQL. Daily backups, one-click restore. Just connect and start querying.Learn more](/services/postgresql)[Email ServiceSend receipts, password resets, and notifications. 3,000 emails included every month.Learn more](/services/email)

## Your app deserves to be online

€5 of credit on signup. Deploy in under a minute. No credit card needed.

[Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app)

---

Source: https://runsite.app/services/cron-jobs
