CronOperation

A CronOperation creates Operations on a schedule, like Kubernetes CronJobs. Use CronOperations for recurring operational tasks such as database backups, certificate rotation, or periodic maintenance.

How CronOperations work

CronOperations contain a template for an Operation and create new Operations based on a cron schedule. Each scheduled run creates a new Operation that executes once to completion.

 1apiVersion: ops.crossplane.io/v1alpha1
 2kind: CronOperation
 3metadata:
 4  name: daily-backup
 5spec:
 6  schedule: "0 2 * * *"  # Daily at 2 AM
 7  concurrencyPolicy: Forbid
 8  successfulHistoryLimit: 5
 9  failedHistoryLimit: 3
10  operationTemplate:
11    spec:
12      mode: Pipeline
13      pipeline:
14      - step: backup
15        functionRef:
16          name: function-database-backup
17        input:
18          apiVersion: fn.crossplane.io/v1beta1
19          kind: DatabaseBackupInput
20          retentionDays: 7

Key features

• Standard cron scheduling syntax - Uses the same format as Kubernetes CronJobs
• Configurable concurrency policies (Allow, Forbid, Replace)
• Automatic cleanup of old Operations - Maintains history limits
• Tracks run history and running operations - Provides visibility into scheduled runs

Scheduling

CronOperations use standard cron syntax:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
│ │ │ │ │
│ │ │ │ │
* * * * *

Common schedule examples:

• "0 2 * * *" - Every day at 2:00 AM
• "0 0 * * 0" - Every Sunday at midnight
• "0 0 1 * *" - Every month on the first at midnight
• "*/15 * * * *" - Every 15 minutes

Concurrency policies

CronOperations support three concurrency policies:

• Allow (default): Multiple Operations can run simultaneously. Use this when operations don’t interfere with each other.
• Forbid: New Operations don’t start if previous ones are still running. Use this for operations that can’t run concurrently.
• Replace: New Operations stop running ones before starting. Use this when you always want the latest operation to run.

History management

Control the number of completed Operations to keep:

1spec:
2  successfulHistoryLimit: 5  # Keep 5 successful operations
3  failedHistoryLimit: 3      # Keep 3 failed operations for debugging

This helps balance debugging capabilities with resource usage.

Common use cases

Scheduled database backups

 1apiVersion: ops.crossplane.io/v1alpha1
 2kind: CronOperation
 3metadata:
 4  name: postgres-backup
 5spec:
 6  schedule: "0 3 * * *"  # Daily at 3 AM
 7  concurrencyPolicy: Forbid  # Don't allow overlapping backups
 8  operationTemplate:
 9    spec:
10      mode: Pipeline
11      pipeline:
12      - step: backup
13        functionRef:
14          name: function-postgres-backup
15        input:
16          apiVersion: fn.crossplane.io/v1beta1
17          kind: PostgresBackupInput
18          instance: production-db
19          s3Bucket: db-backups

Scheduled maintenance

 1apiVersion: ops.crossplane.io/v1alpha1
 2kind: CronOperation
 3metadata:
 4  name: weekly-maintenance
 5spec:
 6  schedule: "0 3 * * 0"  # Weekly on Sunday at 3 AM
 7  operationTemplate:
 8    spec:
 9      mode: Pipeline
10      pipeline:
11      - step: cleanup-logs
12        functionRef:
13          name: function-log-cleanup
14        input:
15          apiVersion: fn.crossplane.io/v1beta1
16          kind: LogCleanupInput
17          retentionDays: 30
18      - step: update-certificates
19        functionRef:
20          name: function-cert-renewal

Periodic health checks

 1apiVersion: ops.crossplane.io/v1alpha1
 2kind: CronOperation
 3metadata:
 4  name: health-check
 5spec:
 6  schedule: "*/30 * * * *"  # Every 30 minutes
 7  operationTemplate:
 8    spec:
 9      mode: Pipeline
10      pipeline:
11      - step: check-cluster-health
12        functionRef:
13          name: function-health-check
14        input:
15          apiVersion: fn.crossplane.io/v1beta1
16          kind: HealthCheckInput
17          alertThreshold: 80

Advanced configuration

Complex scheduling patterns

Advanced cron schedule examples for specific use cases:

 1# Weekdays only at 9 AM (Monday-Friday)
 2schedule: "0 9 * * 1-5"
 3
 4# Every 4 hours during business days
 5schedule: "0 8,12,16 * * 1-5"
 6
 7# First and last day of each month
 8schedule: "0 2 1,L * *"
 9
10# Every quarter (1st of Jan, Apr, Jul, Oct)
11schedule: "0 2 1 1,4,7,10 *"
12
13# Business hours only, every 2 hours
14schedule: "0 9-17/2 * * 1-5"

Starting deadline

CronOperations support a startingDeadlineSeconds field that controls how long to wait after the scheduled time before considering it too late to create the Operation:

 1apiVersion: ops.crossplane.io/v1alpha1
 2kind: CronOperation
 3metadata:
 4  name: deadline-example
 5spec:
 6  schedule: "0 9 * * 1-5"  # Weekdays at 9 AM
 7  startingDeadlineSeconds: 900  # 15 minutes
 8  operationTemplate:
 9    spec:
10      mode: Pipeline
11      pipeline:
12      - step: morning-tasks
13        functionRef:
14          name: function-morning-tasks

If the Operation can’t start in 15 minutes of 9 AM (due to controller downtime, resource constraints, etc.), the scheduled run is skipped.

Skip operations for:

• Time-sensitive operations - Skip operations that become meaningless if delayed
• Resource protection - Prevent backup Operations piling up during outages
• SLA compliance - Ensure operations run in acceptable time windows

Time zone considerations

Status and monitoring

CronOperations provide status information about scheduling:

 1status:
 2  conditions:
 3  - type: Synced
 4    status: "True"
 5    reason: ReconcileSuccess
 6  - type: Scheduling
 7    status: "True"
 8    reason: ScheduleActive
 9  lastScheduleTime: "2024-01-15T10:00:00Z"
10  lastSuccessfulTime: "2024-01-15T10:02:30Z"
11  runningOperationRefs:
12  - name: daily-backup-1705305600

Key status fields:

• Conditions: Standard Crossplane conditions (Synced) and CronOperation-specific conditions:
  • Scheduling: True when the CronOperation is actively scheduling operations, False when paused or has incorrect schedule syntax
• lastScheduleTime: When the CronOperation last created an Operation
• lastSuccessfulTime: When an Operation last completed successfully
• runningOperationRefs: Running Operations

Events

CronOperations emit events for important activities:

• CreateOperation (Warning) - Scheduled operation creation failures
• GarbageCollectOperations (Warning) - Garbage collection failures
• ReplaceRunningOperation (Warning) - Running operation deletion failures
• InvalidSchedule (Warning) - Cron schedule parsing errors

Monitoring

Monitor CronOperations using:

1# Check CronOperation status
2kubectl get cronoperation my-cronop
3
4# View recent Operations created by the CronOperation
5kubectl get operations -l crossplane.io/cronoperation=my-cronop
6
7# Check events
8kubectl get events --field-selector involvedObject.name=my-cronop

Best practices

Scheduling considerations

1. Consider time zones - CronOperations use the host’s local time (same as Kubernetes CronJobs)
2. Plan for long-running operations - Ensure operations complete before next scheduled run
3. Set reasonable history limits - Balance debugging needs with cluster resource usage

Concurrency policies

1. Choose appropriate concurrency policies:
   • Forbid for backups, maintenance, or operations that must complete alone
   • Replace for health checks or monitoring where latest data is most important
   • Allow for independent tasks that can run simultaneously

For general Operations best practices including function development and operational considerations, see Operation best practices.

Troubleshooting

CronOperation not creating Operations

1. Check the cron schedule syntax
2. Verify the CronOperation has Synced=True condition
3. Look for events indicating schedule parsing errors

Operations failing often

1. Check Operation events and logs
2. Verify function capabilities include operation
3. Review retry limits and adjust as needed

Resource cleanup issues

1. Verify you set history limits appropriately
2. Check for events about garbage collection failures

Next steps

• Learn about Operation for one-time operational tasks
• Learn about WatchOperation for reactive operations
• Get started with Operations to try scheduling your first operation