How to Schedule Automated Test Runs at Custom Cron Intervals

Automated tests only create leverage when they run reliably, at the right cadence, against the right environment. Most teams start with “run everything on every pull request,” then discover the reality: end-to-end suites have cost. They consume time, infrastructure, and attention. The answer is not fewer tests. It is better scheduling.

Shiplight AI is built for AI-native teams that need trustworthy UI verification in real browsers without inheriting a maintenance tax. Alongside on-demand and CI-triggered runs, Shiplight supports scheduled test runs so you can continuously verify critical flows and catch UI regressions before users do, even when there is no active development signal to trigger CI.

This guide explains how to schedule test runs to execute automatically at custom cron intervals, how to choose the right cadences, and how to operationalize schedules so they stay useful as your product evolves.

Why cron-based scheduling belongs in modern QA operations

CI triggers are event-driven: a pull request opens, a branch merges, a deployment happens. That is essential, but it is not sufficient.

Cron scheduling fills the gaps that event-driven testing cannot cover:

• Detecting time-based drift: flaky third-party dependencies, expiring tokens, cache behavior, and background jobs can break user journeys between releases.
• Keeping production-like environments honest: staging environments get silently misconfigured. A nightly or hourly run catches it before a “hotfix scramble.”
• Creating predictable observability: when runs happen on a consistent schedule, trend lines (failure rate, duration, flakiness) become meaningful.

Shiplight’s model complements this approach: intent-based execution and self-healing reduce the operational pain of running tests frequently, while dashboards and reporting help you interpret what the schedule is telling you.

Cron basics that matter for test scheduling

Most cron formats use five fields:

minute hour day-of-month month day-of-week

A few systems support a sixth “seconds” field, so always confirm what your scheduler expects. If you are configuring custom cron intervals in Shiplight’s scheduling UI, follow the format it requests. If you are scheduling runs via your CI platform and triggering Shiplight through a CLI or API, follow the CI platform’s cron syntax.

Here are common, safe patterns in standard 5-field cron:

Two details matter more in QA than they do in many other cron use cases:

1. Time zones and daylight savings: “2:30 AM” is not a stable moment everywhere. Decide whether your schedules should follow a business time zone or UTC, then document it.
2. Concurrency and overlap: if a scheduled run can take longer than its interval, you need a plan. Either slow the cadence, reduce the scope, or ensure your runner capacity and scheduling rules prevent pileups.

Choosing the right schedule: cadence by suite type

A cron expression is easy to write. The harder part is picking a schedule that produces signal, not noise.

A practical model is to split your automated coverage into suites that match business risk and change velocity:

• Smoke suite (high frequency): small, fast, and unforgiving. Runs every 15 to 60 minutes, or at minimum every hour during business hours. Focus on login, navigation, checkout, and other “site is usable” flows.
• Critical-path suite (medium frequency): the journeys that drive revenue and retention. Many teams run this every 2 to 6 hours, plus on key deploy events.
• Full regression (low frequency): broad coverage that takes longer. Run nightly, or a few times per week, ideally aligned to off-peak hours.
• Change-sensitive UI checks (targeted frequency): if a particular area is in active redesign, schedule extra runs for that tagged suite while the work is in flight, then scale back afterward.

Shiplight’s strengths map neatly to this structure. When you can generate and maintain end-to-end coverage with minimal test debt, you can afford to run the right tests more often. When self-healing and intent-based execution reduce breakage from harmless UI refactors, scheduled runs become a steady quality heartbeat instead of an alert storm.

Two scheduling approaches that work in practice

There are two common ways teams operationalize cron scheduling with Shiplight.

Scheduling inside Shiplight

If your goal is to centralize test operations, scheduling in the QA platform is clean and auditable:

• You schedule runs directly against a defined test suite.
• You keep ownership close to the team that owns test health.
• You get consistent run history and reporting without coupling schedules to CI configuration.

This approach is particularly useful for staging health checks and continuous UI verification that should run even when the codebase is quiet.

Scheduling in CI and triggering Shiplight

Some teams prefer schedules to live next to deployment workflows. In that model:

• CI runs on a cron schedule.
• CI triggers Shiplight on demand via the method that matches your setup (dashboard-initiated runs for ad hoc use, or CLI/API-triggered runs for automation).
• CI can also orchestrate setup steps (seed data, refresh environments) before tests start.

This is a good fit when scheduled tests must be tightly coupled to environment preparation, or when compliance requires schedules to be managed alongside other production controls.

Making scheduled runs reliable, not just frequent

Scheduling is where good automation programs separate from noisy ones. A few practices dramatically improve trust.

Control test data and environment state. Scheduled runs are repeatability tests. If your data changes unpredictably, your failures will be indistinguishable from real regressions. Use dedicated test accounts, deterministic fixtures, and cleanup routines.

Prevent collision with deploys and heavy jobs. If your staging deploy happens nightly at 2:00 AM, do not schedule a full regression at 2:00 AM. Stagger by 30 to 60 minutes, or schedule post-deploy.

Use tagging and ownership. Organize tests into suites that match who can fix them. A scheduled run that fails without clear ownership tends to get ignored. Shiplight’s suite management and reporting make it easier to keep accountability explicit.

Tune assertions for UI reality. Cron runs often catch visual or rendering regressions that unit tests cannot. Shiplight’s AI-powered assertions are designed for this type of UI verification, especially when the DOM “looks fine” but the page is functionally wrong.

A practical starting point for Shiplight teams

If you want a schedule you can defend and maintain, start small and make it boring:

• Run a smoke suite hourly during business hours.
• Run a critical-path suite nightly.
• Run full regression two or three times per week.
• Add temporary, high-frequency targeted suites during redesigns or major launches.

Then use your run history to refine: shorten the suites that run often, increase cadence only when the signal is clean, and invest in debugging workflows so failures lead to fixes, not fatigue.

The payoff: continuous confidence without the test-suite tax

Custom cron intervals are not a convenience feature. They are a way to turn QA into a measurable, continuous operational practice.

Shiplight AI makes that approach viable for fast-moving teams by reducing maintenance overhead, running real-browser verification that reflects what users see, and giving teams clear reporting they can act on. When scheduled runs are designed well, they stop being “extra automation” and start functioning like a quality radar that is always on.