Scheduling Workflows
Testkube supports a cron-based scheduling mechanism that allows you to run your Test Workflows at desired intervals/times.
Scheduling a Workflow by updating the Workflow Definition
Schedules are defined in the Workflow YAML under a spec.events.cronjob
property - Read More.
The easiest way to schedule your Workflow is to modify the Workflow definition and add the corresponding
spec.events.cronjob
property, for example the below workflow will be scheduled to run on a daily basis at 3 am:
kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
name: distributed-k6-demo
namespace: testkube
spec:
events:
- cronjob:
cron: 0 3 * * *
timezone: America/New_York
...
Testkube uses the same scheduling format as Kubernetes Cron jobs. For details on the cron expression syntax, refer to the Wikipedia Cron format for details.
The timezone value in Testkube is also based on the tz database, consistent with Kubernetes Cron jobs. If no timezone is specified, Testkube will fall back to the cluster’s local time (usually the system time of the node running the job). For a list of supported time zones, see the List of tz database time zones for details.
Schedule a Workflow from the Testkube Dashboard
You can also schedule a Test Workflow from the Testkube Dashboard under the Workflow Settings/Scheduling Panel:
This will add the corresponding YAML to the Workflow definition:
The Dashboard will only allow you to manage one schedule, if you want to define multiple schedules, you will have to do this directly in the Workflow Definition.
Scheduling Architecture
Testkube uses the scheduling engine from Kubernetes Cron jobs for scheduling your Workflow Executions. For each schedule, a special cron job is created from this template.
Technically, it is a callback to the Testkube API server method, launching the corresponding Workflow execution.
The call is executed using curl command from the image curlimages/curl
, please make sure it's available in your Kubernetes cluster.
As of May 1, 2025, the Testkube Agent includes a built-in cron scheduler, now used as the default mode, replacing Kubernetes Cron jobs.
This internal scheduler uses RPC (Remote Procedure Call) to trigger Test Workflows directly, eliminating the need to create separate CronJob pods.
As a result, it significantly reduces Kubernetes resource usage and scales efficiently, even with a large number of scheduled Test Workflows.
After switching to the Testkube Agent's built-in cron scheduler, existing Kubernetes CronJobs will be automatically removed by both the Agent and the Operator during startup.
You can always swicth between Agent and Operator crons using helm chat variables, both either should be true
or false
cronJobs:
## Should it manage cron jobs
enabled: true
and
# -- Agent cron jobs for scheduling test, suites, workflows
agentCronJobs: true