Scheduling automated test runs at custom cron intervals

Pull request checks catch obvious breakage. They do not catch the slow drift that happens between merges: third-party outages, expired test data, flaky dependencies, performance regressions, and UI changes that land outside your team’s immediate line of sight.

That is where scheduled test runs earn their keep. With Shiplight AI, you can run suites on a predictable cadence, hourly, nightly, or at custom cron intervals, and get reliable, browser-based verification without turning test maintenance into a second job.

This guide covers how to think about cron scheduling, how to choose the right intervals, and how teams typically operationalize scheduled runs with Shiplight’s scheduled and on-demand execution, cloud runners, reporting, and hooks.

Why cron-based scheduling is different from run nightly

“Nightly” is a blunt instrument. Cron gives you precision:

• Run a smoke suite every 10 minutes during business hours, when incidents are most expensive.
• Run a deeper regression suite at off-peak hours to control cost and reduce contention.
• Run specific suites around known risk windows, like just before a daily data refresh or right after a partner API batch job.

Cron schedules are also easier to standardize across teams, because the same pattern can be used whether you schedule runs in a testing platform or trigger them from CI.

Cron intervals without the foot-guns

Cron is deceptively simple. Most systems use a five-field format:

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

A few platforms add a sixth “seconds” field. Because implementations vary, treat cron as a shared concept, then confirm the exact format wherever you configure it.

What matters operationally is not the syntax, but the behavior.

Time zones and daylight savings

Cron schedules are evaluated in a specific time zone, and that time zone choice determines whether “2:00 AM daily” is stable year-round. If your schedule is tied to human workflows (for example, “run before standup”), use a consistent team time zone and be explicit about it wherever schedules are configured.

If your schedule is tied to system load (for example, “run when traffic is lowest”), consider anchoring to UTC to avoid daylight savings surprises.

Overlaps, backlogs, and runaway queues

If a suite takes longer than its schedule interval, you can end up with overlapping runs. High-signal scheduled testing is designed to finish comfortably before the next trigger.

As a rule of thumb:

• Smoke and critical path suites should run fast and frequently.
• Full regression should run less frequently, but with enough depth to catch slow burn issues.

Shiplight’s cloud runners and parallel execution help keep schedules realistic even as coverage grows, but it is still worth designing suites with runtime and purpose in mind.

Common schedules that work in practice

Below are example cron patterns in the common five-field format. Use them as a starting point, then adapt for your environment and time zone.

Two practical notes:

• If your cron system uses a different day-of-week mapping or includes seconds, adjust accordingly.
• Avoid “every minute” unless you have a clear incident-response reason. It tends to produce noise and cost without improving outcomes.

Ways to execute scheduled runs with Shiplight AI

Shiplight supports both scheduled runs and on-demand execution, which gives teams flexibility in how they operationalize cron-based testing. In practice, there are two reliable patterns.

Scheduling inside Shiplight

If you want the simplest operational setup, schedule runs directly in Shiplight.

This model works well when:

• You want schedules owned by QA, product, or release owners, not buried in CI YAML.
• You want scheduled runs to show up consistently in Shiplight’s dashboards and reporting, with a clear history of what ran and when.
• You rely on Shiplight’s cloud runners for scalable execution across browser environments.

A clean way to structure this is to schedule at the suite level, where each suite represents a clear intent:

• Smoke: “Is the site usable right now?”
• Critical path: “Can users complete the core journey?”
• Regression: “Did anything else break?”

Shiplight’s intent-based execution and self-healing approach are especially valuable here, because scheduled runs tend to expose the kind of UI drift that breaks brittle selector-based automation. The point of cron is consistency. If the suite is constantly red for tooling reasons, the schedule becomes meaningless.

Scheduling in CI and triggering Shiplight

If your organization centralizes scheduling in CI, you can keep the cron trigger there and use it to kick off Shiplight runs.

This model works well when:

• You already manage other scheduled jobs in CI (data refreshes, security scans, backups) and want one place for orchestration.
• You need the schedule to align with deploy workflows or environment operations that also live in CI.
• You want to chain jobs: set up data, run Shiplight suites, then post results to downstream systems.

For example, GitHub Actions supports cron scheduling via on: schedule, and Jenkins supports cron-like triggers for jobs. In those setups, you typically trigger the same Shiplight run method you use for pull requests, just on a time-based schedule instead of a code event.

Keeping scheduled runs high-signal

The best cron schedule is the one your team trusts. These practices help you get there.

• Separate monitoring from validation. A frequent smoke suite should behave like a heartbeat. Keep it short, deterministic, and focused on the critical path. Save exploratory breadth for nightly and weekly runs.
• Tag by risk and ownership. Organize suites so a failure routes cleanly to the team that can fix it. Scheduled runs are only as useful as the speed of triage.
• Use evidence-rich failures. Scheduled runs often fail when nobody is actively watching. Make sure the results are reviewable after the fact with the context needed to act quickly.
• Close the loop with hooks. When a critical scheduled run fails, route it where decisions happen: your incident channel, ticketing system, or release dashboard. Shiplight’s webhook and custom hook integrations are designed for exactly this kind of workflow wiring.
• Design for UI change, not against it. If your application ships frequently, UI evolution is normal. Shiplight’s self-healing tests and intent-based execution help keep scheduled verification stable as the interface changes, so cron schedules stay meaningful over time.

The outcome: confidence that does not depend on perfect timing

Cron scheduling is not about running more tests. It is about running the right tests at the right cadence, so you catch regressions when they are cheapest to fix and most likely to matter.

Shiplight AI makes scheduled testing practical for AI-native teams by reducing the operational drag that usually comes with end-to-end automation: brittle selectors, constant maintenance, and dashboards that look green until they suddenly do not. With scheduled and on-demand runs, cloud execution, and reporting built for real workflows, you can turn cron intervals into continuous verification your team actually trusts.