TestInspector supports three scheduling trigger types for automated tests: cron expressions for recurring tests on a time-based schedule, interval triggers for tests that run every fixed number of minutes or hours, and one-time triggers for a single future execution. All three are configured within TestInspector without connecting to an external CI/CD pipeline, build server, or task scheduler. This means teams can schedule tests as soon as they are written, with no pipeline configuration required. The scheduling system operates within the TestInspector test hierarchy — tests can be scheduled at the suite level, and environment variables and secrets apply to scheduled runs using the same variable interpolation available for manual runs.

Scheduling is a practical capability gap in many automated testing setups. Teams that use CI/CD-triggered test runs for deployment verification still need to run tests on a schedule for smoke testing production environments, monitoring external API behavior, or running regression suites overnight when CI pipeline time is limited during the working day. TestInspector's built-in scheduling removes the need to configure a separate cron job, a GitHub Actions scheduled workflow, or an AWS EventBridge rule to trigger test runs against a platform that does not natively understand schedules. This guide covers how each trigger type works in TestInspector, how to configure them, and how scheduled runs compare to CI/CD-triggered runs in terms of appropriate use cases. For teams evaluating test scheduling infrastructure, Astaqc's test automation services cover both native scheduling implementations and CI/CD integration strategies, and the complete software testing guide provides context on where scheduling fits in a broader automated testing programme.

How TestInspector's Scheduling System Works

TestInspector scheduling operates at the suite level. A schedule is attached to a suite and applies to all tests within that suite when the trigger fires. Schedules persist independently of the test runner: they remain active when the TestInspector application is not in use and continue firing as long as the suite is configured with an active schedule. The platform handles trigger evaluation server-side, so tests fire on schedule without any local process running.

When a scheduled trigger fires, TestInspector creates a run identical to a manually triggered run. The run uses the browser configuration, variable set, and environment specified in the schedule configuration. Live WebSocket streaming is available for scheduled runs in the same way as manual runs: if the run dashboard is open when a scheduled trigger fires, the test steps execute in real time in the streaming view. Results are recorded and available in run history when next accessed.

Variable interpolation is fully available in scheduled runs. Tests that use {{TIMESTAMP}} variables generate a new value on each scheduled execution. Tests that use {{TOTP:secret}} for time-based one-time password login generate the correct TOTP code for the moment the scheduled trigger fires. Encrypted variables at the org, suite, and test levels apply to scheduled runs using the same hierarchy as manual runs. This means login credentials, API keys, and environment-specific configuration are available to scheduled runs without being embedded in the test steps themselves.

TestInspector supports Selenium-based execution on Chrome, Firefox, Edge, and Safari. Scheduled tests execute on whichever browser is specified in the suite's run configuration. A common pattern is to schedule a nightly regression suite on Chrome and a weekly cross-browser run that fires the same suite against Firefox and Edge on different schedules. Each schedule is an independent configuration, so multiple schedules can target the same suite with different browser and variable configurations.

Cron Scheduling in TestInspector

Cron scheduling in TestInspector uses standard cron expression syntax: five fields specifying minute, hour, day of month, month, and day of week. A cron expression like 0 2 * * * fires at 2:00 AM every day; 0 8 * * 1-5 fires at 8:00 AM Monday through Friday; 0 */4 * * * fires every four hours. TestInspector evaluates cron expressions against UTC, and the schedule configuration accepts a timezone offset so teams can specify schedules in local time without calculating UTC offsets manually.

Cron scheduling is the appropriate trigger type for recurring tests that should run at specific times relative to the clock. Common use cases include nightly regression runs after CI queues are quiet, morning smoke tests before the working day begins, and end-of-week full suite runs to catch regressions before the weekend. Cron is also appropriate for tests that need to fire at the same time in relation to a business process: running payment processing tests at 1 AM when batch settlement jobs complete, or verifying data pipelines at 7 AM when overnight ETL jobs are scheduled to finish.

Unlike interval triggers, cron expressions fire at wall-clock times regardless of when the last run completed. A cron-scheduled test that runs every day at 2 AM fires at 2 AM regardless of how long the previous run took. Cron scheduling does not attempt to compensate for missed triggers: if a scheduled run fails to start due to a platform issue, the next run fires at the next occurrence of the cron expression without catching up. For scenarios where every execution must complete regardless of gaps, an interval trigger is a better fit.

The self-healing capability in TestInspector applies to cron-triggered runs. If a test step fails because a selector has changed since the last run, TestInspector's AI selector suggestion generates an alternative selector for review. This is particularly relevant for scheduled smoke tests running against production or staging environments where the application changes over time: cron-triggered runs continue finding elements using the best available selector rather than failing the entire run on the first mismatch.

Interval and One-Time Trigger Scheduling

Interval triggers fire every N minutes or hours starting from a defined start time. Unlike cron, interval triggers do not fire at specific clock times — they fire at a fixed duration after the previous execution. A 30-minute interval starting at 8 AM fires at 8:00, 8:30, 9:00, and so on, maintaining the 30-minute gap between executions. Interval triggers are appropriate when the frequency of execution matters more than the specific time of execution.

The most common use case for interval triggers is continuous smoke testing of production or staging environments. A 15-minute interval trigger running a login-to-dashboard smoke test provides near-continuous uptime monitoring: if the login flow breaks, the next interval run fails within 15 minutes and the failure is visible in run history. Compared to synthetic monitoring tools that only check HTTP status codes, interval-based tests in TestInspector cover the full user flow with the full test step sequence. Visual regression comparison is available in interval-triggered runs, so a scheduled smoke test can detect unexpected visual changes to the homepage or login screen as part of the interval run.

One-time triggers schedule a test or suite to run once at a specified future time. One-time triggers are useful for scheduling a final pre-deployment regression run, running a test against a feature branch deployment before a release window, or scheduling a test run to start outside normal working hours when manual triggering is not practical. Once a one-time trigger fires, it does not repeat. The run history shows the scheduled time, the actual run start time, and the run duration, which confirms whether the trigger fired as expected.

HTTP request steps in TestInspector are fully supported in scheduled runs, including interval and one-time triggers. Tests that exercise REST API endpoints using GET, POST, PUT, PATCH, or DELETE steps with status code and body assertions work in all three trigger types. This means interval-triggered API monitoring — checking that a GET /health endpoint returns 200 with the expected JSON body every 5 minutes — is achievable within TestInspector without a separate API monitoring tool. The variable interpolation system supplies authentication tokens and dynamic values to each scheduled API test step. For teams integrating TestInspector with their CI/CD pipeline, Astaqc's test automation services provide guidance on which test types suit CI-triggered versus scheduled runs, and Astaqc's QA team service covers ongoing scheduled test maintenance.

How Scheduled Runs Compare to CI/CD-Triggered Runs

CI/CD-triggered runs and scheduled runs serve different purposes. CI/CD-triggered runs fire in response to a code event: a commit, a pull request, a deployment. The test verifies that the change did not introduce a regression. CI/CD integration in TestInspector uses the API trigger endpoint: the CI pipeline makes an HTTP call to start a TestInspector run and optionally waits for the result to determine whether the deployment should proceed.

Scheduled runs are not tied to a code event. They fire on time-based conditions regardless of whether code has changed. Scheduled runs are appropriate for three categories of test. Production environment monitoring: tests that verify the live production application is functioning correctly cannot run in a CI pipeline because CI pipelines target pre-production environments. Interval-triggered runs against the production URL detect outages, broken authentication flows, or degraded third-party integrations that only affect production. Regression suites too slow for CI: full regression suites that take 30 to 60 minutes to run are often impractical in a CI pipeline where developers expect feedback within 10 minutes. Scheduling these suites to run nightly allows comprehensive coverage without blocking CI pipeline speed. Data-dependent tests: tests that rely on specific data states — end-of-month reports, batch job outputs, nightly import completions — can only run correctly after the dependent process finishes.

A complete test strategy typically uses both trigger types: CI/CD triggers for deployment verification and scheduled triggers for continuous monitoring and nightly regression. The run history shows both trigger types, making it straightforward to distinguish deployment-triggered failures from environment-introduced failures discovered by the scheduled run. For more context on integrating automated testing into delivery pipelines, see the QA outsourcing guide, testing documentation services, and the TestInspector product page.

Frequently Asked Questions

Does TestInspector scheduling require the desktop application to be running?

No. TestInspector schedules are evaluated server-side, so scheduled triggers fire regardless of whether the TestInspector application or browser session is open. Results are recorded and available in run history when the dashboard is next accessed. The WebSocket live streaming view is only active when a user has the run dashboard open, but the scheduled run executes and records results independently of any active session.

Can different browser configurations be used in separate schedules for the same suite?

Yes. Each schedule is an independent configuration. A suite can have one cron schedule targeting Chrome and a separate schedule targeting Firefox, each with different environment variable sets. This is a common pattern for nightly cross-browser regression: different schedules fire the same test suite against each browser, producing separate run records per browser in the history.

What happens if a scheduled run is still executing when the next scheduled trigger fires?

TestInspector starts a new run for each trigger occurrence independently of whether the previous run is still executing. This means two instances of the same suite can run simultaneously if an interval is shorter than the typical run duration. For suites where concurrent execution would cause database conflicts or shared state issues, setting the interval longer than the typical run duration avoids overlapping executions.

Can scheduled runs use TOTP authentication for tests that require two-factor login?

Yes. TestInspector's {{TOTP:secret}} variable generates the correct six-digit TOTP code at the moment the test step executes. This applies identically to manual, CI-triggered, and scheduled runs. The TOTP secret is stored as an encrypted variable and is never exposed in run logs or history. Scheduled smoke tests that include a two-factor login step work without any special handling compared to a regular login test.

How do I verify that a one-time scheduled run executed as expected?

Run history in TestInspector shows the trigger type, the scheduled time, the actual start time, the completion time, and the pass/fail result for each step. A one-time run shows its scheduled time alongside the actual start time, confirming whether the trigger fired on time. If the actual start time is more than a few seconds after the scheduled time, this indicates queue latency; if the run is absent entirely, the schedule should be checked to confirm it was saved with the correct date and time.

Is there a limit to how many active schedules a TestInspector account can have?

Schedule limits depend on the account plan. The scheduling feature is available across plans, but the number of concurrent active schedules and minimum interval duration may vary. For high-frequency interval monitoring across many suites, confirming the plan limits before configuring avoids unexpected throttling. The TestInspector product page provides current plan details, and Astaqc's software testing services team can advise on plan selection based on monitoring frequency requirements.