Skip to content

cronjob.mdx

Latest commit

 

History

History
237 lines (172 loc) · 7.03 KB

cronjob.mdx

File metadata and controls

237 lines (172 loc) · 7.03 KB
Raw
title Cron Jobs
description Schedule and manage periodic workloads on Qovery

Overview

Cron Jobs in Qovery are Kubernetes workloads that run on a regular schedule. They are perfect for recurring tasks such as pulling data from external services periodically or processing accumulated data.

Common Use Cases:

  • Pull data from external APIs at regular intervals
  • Process and transform database data
  • Generate scheduled reports
  • Clean up old records
  • Perform database backups
  • Run maintenance scripts

Dedicated Cronjob Node Pool

On AWS EKS clusters with Karpenter, you can enable a dedicated **cronjob node pool**. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a required node affinity toward this node pool, so they always run there. See [AWS EKS cluster resources](/configuration/integrations/kubernetes/eks/managed#resources) for details on enabling and configuring this nodepool. Whenever you enable or disable the cronjob node pool, **you must redeploy every cron job** so they pick up the updated scheduling configuration. The node affinity is required (hard), so:
  • Cron jobs deployed before the nodepool was enabled will not run on it until they are redeployed.
  • Cron jobs deployed while the nodepool was enabled will stay in Pending if the nodepool is later disabled and they are not redeployed.

There is no automatic fallback to the default node pool. Always redeploy your cron jobs after touching this setting.

Deployment Sources

Qovery supports two deployment sources for Cron Jobs:

Git Repository

Qovery pulls your code from a Git repository, builds the application, and deploys it to your Kubernetes cluster.

Supported Providers: GitHub, GitLab, Bitbucket

Container Registry

Qovery pulls a pre-built container image from your configured registry and deploys it to your Kubernetes cluster.

The tag `latest` is not supported. Please use a specific tag for container images.

Creating a Cron Job

Choose **Git Repository** or **Container Registry** as your deployment source **For Git Repository**: - Select Git provider - Choose repository - Select branch - Specify root path (if not at repository root) - Configure Dockerfile path 
**For Container Registry**:
- Select configured registry
- Enter image name
- Specify image tag (not `latest`)
- **CRON Schedule**: Define when the job should run - **Timezone**: Set timezone for schedule - **Entrypoint**: Override container entrypoint (optional) - **CMD Arguments**: Provide command arguments (optional) - **Restart Policy**: Configure failure handling - **Max Duration**: Set execution timeout - **Port**: Configure if job exposes a port (optional) - **vCPU**: Default 500m (0.5 cores) - **RAM**: Default 512MB Configure environment variables for your job Review configuration and click **Create** to deploy

Configuration

General Settings

Name: Unique identifier for your Cron Job within the environment

Source Configuration:

  • Git: Provider, repository, branch, root path, Dockerfile
  • Registry: Image name and specific tag

Job Configuration

CRON Schedule: Define when your job should run using CRON syntax:

* * * * *
│ │ │ │ │
│ │ │ │ └── Day of week (0-7)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Common Examples:

  • */5 * * * * - Every 5 minutes
  • 0 * * * * - Every hour
  • 0 0 * * * - Daily at midnight
  • 0 2 * * 0 - Weekly on Sunday at 2 AM

Timezone: Set the timezone for your CRON schedule (default: UTC)

Entrypoint: Override the default container entrypoint if needed

CMD Arguments: Provide command-line arguments to pass to the container

Restart Policy:

  • Never: Job runs once per schedule (recommended for Cron Jobs)
  • OnFailure: Automatically restart if job fails

Max Duration: Maximum execution time before the job is terminated (in seconds)

Port: Configure if your job exposes a port for health checks

Resources

  • vCPU: CPU allocation in millicores (default: 500m)
  • Memory: RAM allocation (default: 512MB)

Health Checks

Configure optional health checks:

  • Liveness Probe: Determines if container should be restarted
  • Readiness Probe: Determines if container is ready to execute

Deployment Restrictions

Control when deployments should be triggered:

  • File path filters: Deploy only when specific files change
  • Branch filters: Deploy only from specific branches

Force Run

Manually trigger a Cron Job execution outside its schedule:

Go to your Cron Job in the Qovery console Click the **Play** button or **Force Run** action View real-time logs and verify successful completion Force Run executions do not affect the regular schedule. The job will still run at its next scheduled time.

Clone Service

You can create a clone of the service via the clone feature. A new service with the same configuration will be created into the target environment.

Go to the Cron Job you want to clone Click on the **three dots button** and select **Clone** Choose the target environment where you want to clone the service The target environment can be the same as the current environment or a different one in a completely different project.

Delete Cron Job

To delete a Cron Job:

  1. Navigate to the Cron Job settings
  2. Click the three-dot menu → Delete
  3. Confirm deletion
Deleting a Cron Job is permanent and cannot be undone.

Related Resources

Run jobs triggered by environment lifecycle events Manage configuration and secrets for your jobs Configure registries for container-based jobs Configure advanced job options