Skip to content

PATTERN Cited by 1 source

Scheduled cron-triggered load test

What this is

Scheduled cron-triggered load test is the pattern of running load tests on a recurring schedule via a cron scheduler (typically a Kubernetes CronJob) that calls the same declarative load-test API a human operator would call, rather than running load tests only before major launches. Frequent, scheduled runs make the load test "the first quality gate" of the system, not a pre-Cyber-Week ritual.

Why scheduled

  • Regression detection. Code changes, dependency updates, and infrastructure shifts silently move the system's capacity envelope. A weekly scheduled run catches regressions within days, not months.
  • Trend data. Repeated runs of the same declarative spec produce a time-series of capacity that is far more informative than a pre-launch single-shot number.
  • Forcing-function for parity. Infrastructure layer drift in the test cluster (a database that got smaller, a shared queue that got re-tuned) shows up the next time the scheduled run fails or reports a degradation. Without scheduled runs, drift accumulates silently until the manual pre-launch run produces a panic.
  • Low marginal operator cost. Once the conductor is in place, the scheduled trigger costs nothing to add.

Shape (Zalando instantiation)

Source: sources/2021-03-01-zalando-building-an-end-to-end-load-test-automation-system-on-top-of-kubernetes:

  • Kubernetes CronJob calls the Load Test Conductor's HTTP API on a schedule.
  • Same endpoint the developer manually curls — no parallel invocation path.
  • Target spec is stored alongside the CronJob manifest as a ConfigMap or inline env var.

The API unification discipline

Manual developer trigger + scheduled CronJob + (conceivably) CI pre-release gate + Slackbot command all must hit the same API, driving the declarative-API discipline described in concepts/declarative-load-test-api. Two consequences:

  • No branching logic inside the conductor. The conductor doesn't know who called it.
  • Audit trail is homogeneous. Every run is an API invocation, with the same logs and the same lifecycle phases.

If scheduled runs go through a different code path, they drift in behaviour from manual runs, and one path rots.

Failure-surface considerations

  • CronJob running during a production incident — a load test mid-incident amplifies load on shared infrastructure (databases, event bus). The conductor needs a kill-switch that disables scheduled runs; on-call can hit it to suppress the cron.
  • Scheduled run during a deploy window — Zalando explicitly names this as unsolved: unrelated deploys can race with the Scaler. A scheduling discipline that avoids overlap with known change windows helps.
  • Alert fatigue from recurring failures. A failed scheduled load test is a real regression in some cases and a flake in others. Without investigation, scheduled runs degrade into noise.

When this is worth it

  • You already have a declarative conductor. Scheduled runs atop an imperative script is usually a bad idea — the orchestration's failure modes get hit frequently with nobody watching.
  • The capacity number is business-relevant — so a regression matters. Teams without a KPI-driven capacity commitment rarely need scheduled runs.
  • Observability investment is in place — Grafana dashboards, alerting on SLO breach, automated run-summary artefacts. Otherwise scheduled runs generate noise without signal.

Seen in

Last updated · 476 distilled / 1,218 read