Scheduled Operations

Scheduled operations let you automate recurring tasks on your servers - deploy on a schedule, run maintenance scripts, restart containers, or reboot servers. Operations support cron expressions, pre-execution conditions, retry logic, and chaining multiple operations together.

Operation Types

Type	What it does	Requires
Deploy	Deploys an application to its server	Application
Command	Runs a shell command on a server	Server, command text
Restart	Restarts an application’s Docker container	Server, Application
Reboot	Reboots a server	Server

Creating a Scheduled Operation

1. Navigate to Scheduled Operations in the sidebar
2. Click Create Operation
3. Choose the operation type
4. Configure the schedule (cron or one-time)
5. Set targeting (which server/application)
6. Optionally add conditions and post-actions
7. Click Create

The operation starts in the Active state and will execute according to its schedule.

Schedule Types

Cron (recurring)

Standard 5-field cron expressions for recurring schedules. All times are evaluated in the timezone you specify (defaults to UTC).

# Field order: minute hour day-of-month month day-of-week

0 3 * * *       # Every day at 3:00 AM
*/15 * * * *    # Every 15 minutes
0 0 * * 0       # Every Sunday at midnight
0 9 1 * *       # First day of every month at 9:00 AM
30 2 * * 1-5    # Weekdays at 2:30 AM

Tip

Set the timezone to match your team’s working hours. For example, America/New_York ensures your 3 AM maintenance window is 3 AM Eastern, not UTC.

One-time

Schedule a single execution at a specific date and time. The operation runs once and then stays in the system for history.

Operation Parameters

Deploy

Deploy an application to its server. Optionally specify a git ref to deploy.

Parameter	Description
Application	The application to deploy
Commit ref	Branch, tag, or SHA to deploy (defaults to the app’s deploy branch)

Command

Run a shell command on a server. The command executes via the runner agent.

Parameter	Description
Server	Target server
Command	Shell command to run (max 4,096 characters)

Examples:

# Clean up old Docker images
docker image prune -af --filter "until=168h"

# Run a database backup
pg_dump -U postgres mydb > /backups/mydb-$(date +%Y%m%d).sql

# Clear application cache
cd /opt/app && docker compose exec -T api python manage.py clearcache

Restart

Restart an application’s Docker container. Useful for picking up configuration changes or clearing memory.

Parameter	Description
Server	Target server
Application	Application whose container to restart

Reboot

Reboot a server. If the server has a cloud provider linked, the reboot uses the cloud API. Otherwise, it sends sudo reboot via the runner.

Parameter	Description
Server	Target server

Caution

Reboot will disconnect all running containers and services on the server. Schedule reboots during maintenance windows.

Execution Behavior

Timeout

Each run has a timeout (default: 10 minutes, configurable from 30 seconds to 1 hour). If a run exceeds the timeout, it’s marked as timed out.

Concurrency

When a new trigger fires while a previous run is still executing:

Policy	Behavior	Available for
Skip (default)	Skip the new trigger; let the current run finish	All types
Queue	Queue the new trigger; execute after the current run completes	All types
Replace	Cancel the current run and start the new one	Command only

Retries

Failed runs can be automatically retried:

• Max retries: 0-3 attempts (default: 0, no retries)
• Retry delay: 30-600 seconds between attempts (default: 60 seconds)

If an operation accumulates 5 consecutive failures, it’s automatically paused to prevent cascading issues. Resume it manually after fixing the underlying problem.

Conditions

Conditions are checked before each execution. If any condition fails, the run is skipped.

HTTP Check

Make an HTTP request and verify the response before executing.

Parameter	Description
URL	Endpoint to check
Expected status	HTTP status code to require (e.g., 200)

Use case: Only deploy if the staging health check is passing.

Command Check

Run a shell command on the target server and verify the output.

Parameter	Description
Command	Shell command to execute
Expected output	String the output must contain

Use case: Only run cleanup if disk usage is above a threshold.

Previous Run Check

Verify that another operation’s last run had a specific status.

Parameter	Description
Operation	The other scheduled operation to check
Required status	Status to require (e.g., succeeded)

Use case: Only deploy production after staging deployment succeeded.

Post-Action Chaining

Trigger other scheduled operations after a run completes. This lets you build multi-step workflows.

How it works

1. A parent operation completes (success or failure)
2. Each post-action is evaluated against its trigger condition
3. Matching post-actions create new runs for their target operations
4. Target operations execute with an optional delay

Trigger conditions

Trigger	Fires when
On success	Parent run succeeded
On failure	Parent run failed
Always	Regardless of parent outcome

Chain depth

Operations can chain up to 5 levels deep. This prevents runaway chains.

Deploy staging          (depth 0)
  -> Run tests          (depth 1)
    -> Deploy production  (depth 2)
      -> Health check     (depth 3)

Delay

Each post-action can have a delay of 0-300 seconds before the target operation executes. Use this to wait for services to stabilize before running the next step.

Managing Operations

Pause and Resume

Pause an operation to temporarily stop it from executing. The schedule is preserved and resumes when you reactivate it.

• Pause: The operation stops executing on schedule
• Resume: The operation becomes active and executes at the next scheduled time

Manual Trigger

Trigger an operation immediately, outside its schedule. Useful for testing or one-off executions. Manual triggers respect conditions and concurrency settings.

Run History

Each operation tracks its execution history. For each run, you can see:

• Status (succeeded, failed, timed out, skipped)
• Start and completion time
• Duration
• Output or error message
• Whether it was triggered by schedule, manual action, or chain
• Any child runs it triggered

Deleting Operations

Deleting an operation is a soft delete - the operation and its history are preserved but hidden from the active list.

Limits

Limit	Value
Max operations per organization	Configurable per plan
Command length	4,096 characters
Timeout range	30 seconds - 1 hour
Max retries	3
Retry delay range	30 - 600 seconds
Chain depth	5 levels
Post-action delay	0 - 300 seconds
Auto-pause threshold	5 consecutive failures

Examples

Nightly database backup

Type: Command
Schedule: 0 2 * * * (daily at 2 AM)
Timezone: America/New_York
Command: pg_dump -U postgres mydb | gzip > /backups/mydb-$(date +%Y%m%d).sql.gz
Timeout: 30 minutes

Deploy staging, then production

Operation 1: Deploy Staging

Type: Deploy
Schedule: 0 9 * * 1-5 (weekdays at 9 AM)
Application: my-app-staging

Operation 2: Deploy Production (triggered by Operation 1)

Type: Deploy
Application: my-app-production
Post-action on Operation 1: On success, delay 300 seconds

Weekly Docker cleanup

Type: Command
Schedule: 0 4 * * 0 (Sundays at 4 AM)
Command: docker system prune -af --filter "until=168h"
Timeout: 10 minutes

Restart with health check condition

Type: Restart
Schedule: 0 6 * * * (daily at 6 AM)
Condition: HTTP Check - https://myapp.com/health returns 200
Application: my-app

Only restarts if the health check is currently passing. Skips the restart if the app is already down (to avoid masking the real issue).

Next Steps

• GitHub Actions Integration to trigger operations from CI/CD
• Deployment Configuration to configure how deploys work
• Runner Servers to set up the runner agent on your servers