How to Schedule Automated API Tests in Apidog (Cloud, Runner, and CLI)

A passing test suite only helps if it keeps passing. Your checkout flow works today, but a dependency can ship a breaking change at 2 a.m., a certificate can expire over the weekend, or config drift can take down payments on a Sunday. If an angry customer finds it before your tests do, your checks are not doing their job. The practical fix: run API tests on a schedule and alert the team as soon as something fails.

Try Apidog today

Apidog includes a Scheduled Tasks feature for this workflow. Select existing test scenarios, configure a cadence, choose a machine to execute them, and set up alerts. If you are new to unattended checks against live endpoints, start with this primer on API monitoring. For UI-specific details, use the Apidog Scheduled Tasks documentation.

Scheduled Tasks is currently labeled Beta. The number of scheduled runs available depends on your plan.

What Scheduled Tasks do—and what they do not do

A scheduled task runs one or more saved Test Scenarios on a recurring cycle. Common uses include:

• Nightly regression tests for core API flows
• A staging smoke test every few hours
• Weekend health checks for production endpoints
• Scheduled checks for authentication, payments, or other critical paths

Each task stores:

• The test scenarios to run
• The target environment
• The schedule
• The Runner that executes requests
• Notification settings

Scheduled Tasks are not web scrapers or data-collection jobs. They run API test scenarios, including assertions, chained requests, extracted variables, and test data. The output is a pass/fail report for your API tests—not a scraped dataset.

That changes the setup: you do not configure CSS selectors or crawl rules. You select test scenarios you already built and define when and where they run.

Before you start: configure a self-hosted Runner

Scheduled Tasks require a self-hosted Runner.

A Runner is the machine that executes your test suite. When a task fires, Apidog sends the job to the selected Runner. Requests do not run from your desktop client; they originate from the Runner machine.

Good Runner choices include:

• An always-on VM
• A CI server
• A small server inside your VPC
• A dedicated monitoring host

Make sure the Runner stays online during the scheduled window.

The runner target currently offers:

• Apidog Cloud — marked “coming soon”
• Self-hosted Runner

Because Apidog Cloud is not available yet, select a self-hosted Runner for scheduled execution.

Also account for the Runner's network location. A Runner behind a VPN, in another region, or inside a firewalled subnet may receive different responses than your laptop. This is often useful because it tests the API from a realistic network environment, but it also explains why local and scheduled results can differ.

Step by step: create a scheduled task

This example creates a nightly regression suite for an e-commerce API covering signup, product browsing, cart operations, and checkout with Stripe.

1. Open Scheduled Tasks in the Tests module

In the Apidog client:

1. Open the Tests module.
2. In the Tests folder tree, select Scheduled Tasks.

This view lists scheduled tasks for the current project and shows what is configured to run.

2. Create the task

Click + New to create a scheduled task.

Set a clear task name and description, for example:

Task Name: Nightly regression - production
Description: Validates signup, catalog, cart, and checkout flows against production.

You can also create folders to group tasks. For example:

Scheduled Tasks
├── Production
│   ├── Nightly regression
│   └── Payment smoke test
└── Staging
    ├── Pre-release smoke test
    └── Contract regression

Tasks can be enabled or disabled at any time, so you can pause a noisy suite without deleting its configuration.

3. Select test scenarios

Under Test Scenario, select one or more scenarios.

For an e-commerce regression task, select scenarios such as:

• Signup and login
• Browse and add to cart
• Checkout with Stripe test card

Each scenario can use its own execution settings:

• Environment
• Test data
• Iterations
• Delay
• Whether to save requests and responses

If every scenario should use identical settings, enable Use same execution config. This applies one runtime configuration across all selected scenarios.

For most scheduled suites, keep the environment consistent:

• Use production for real production monitoring.
• Use staging for pre-release smoke tests.

Although a task can use different environments per scenario, a single environment per task is usually easier to operate and troubleshoot.

4. Set the run cycle

Configure the schedule using the run-schedule field. Depending on the UI, this may appear as Run Cycle or Run Mode.

Examples include:

• Every Sunday at 11 PM
• Every 6 hours
• Every 8 hours

Choose a cadence based on risk and test cost:

Use case	Suggested cadence
Production regression suite	Nightly
Staging smoke test	Every 6 hours
Critical health flow	Every few hours
Resource-intensive end-to-end suite	Nightly or weekly

A nightly run is usually a good starting point for broad regression coverage because it catches failures before the next workday without putting unnecessary load on the environment.

5. Choose where the task runs

Set the Runner field to your self-hosted Runner.

Depending on the screen, this may be labeled:

• Runs on
• Run On
• Runs On

All labels refer to the machine that sends the test requests.

If you have multiple Runners, choose the one that best represents the traffic you want to validate. For example, select a Runner in the same VPC as your API if you want to validate internal connectivity.

Remember: every request in the scenario originates from this Runner machine.

6. Enable notifications

Enable Notification so failures reach the team automatically.

Supported channels include:

• Slack
• Teams
• Webhook
• Jenkins
• Email

For email notifications, project member addresses can auto-complete, and you can manually add non-member addresses such as an on-call inbox.

Choose when notifications fire:

• After every run: useful while validating a new task or during an active rollout.
• On failures only: best for stable nightly suites, where silence indicates success.

For example, use failures-only notifications for production regression:

Channel: Slack
When to notify: Failures only
Target: #api-alerts

Use every-run notifications temporarily when you need confirmation that the task itself is executing.

7. Save and enable the task

Save the configuration, then enable the task using its toggle.

The task begins running on the configured cadence. Disable it later if you need to pause monitoring during planned maintenance, an outage, or a migration window.

8. Review run history

After each run, the Runner uploads results back to the server.

Open Scheduled Tasks - Run History to inspect:

• Pass/fail status
• Execution time
• Failed assertions
• Request and response details, if saved
• The time each run occurred

When a Slack or email alert arrives, use Run History to investigate the failing scenario and assertion.

Advanced settings and variations

Once the basic task works, configure variable handling and folder structure carefully.

Variable scope

Apidog provides three levels of variable sharing:

1. Share only in the current test scenario
   
   Keeps variables isolated to one scenario.

2. Share across all test scenarios in the current scheduled task
   
   Allows scenarios in the same task to use shared values.

3. Share across all scheduled tasks in the current scheduled task folder
   
   Lets related tasks inside a folder share variables.

Use the narrowest scope that supports your workflow. For example, avoid sharing an authentication token across unrelated scenarios unless those scenarios explicitly require it.

Variable persistence

To preserve values between scheduled runs, enable Keep variable values on the test scenario design page.

Without this option, each scheduled run starts with fresh variable values.

Enable persistence only when your tests require cross-run state, such as a captured order ID or refreshed token.

Group tasks with folders

Use folders to separate task types:

Scheduled Tasks
├── Production monitors
├── Staging smoke tests
├── Payment checks
└── Pre-release regression

Folders also support the widest scheduled-task variable-sharing scope, which can help related tasks reuse setup data.

Check plan limits before increasing frequency

The number of scheduled runs available depends on your subscription. Before configuring hourly or high-frequency tasks, check your plan limits.

For deeper scheduling patterns, see:

• Advanced scheduled tasks
• Conditional logic in API test scenarios
• Nightly API test runs in CI

Automate with the Apidog CLI

The Scheduled Tasks UI is one option. You can also run saved scenarios headlessly with the Apidog CLI and let cron or your CI platform provide the schedule.

The CLI does not include a native schedule command. Scheduling happens outside Apidog through cron, GitHub Actions, or another CI scheduler.

Install the CLI, authenticate, and run a scenario against a chosen environment:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

The relevant flags are:

Flag	Purpose
-t	Test scenario ID
-e	Environment ID
-r	Reporter format

Available reporters include cli, html, and junit. Combine reporters with commas:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t 4471 \
  -e 88 \
  -r cli,junit

Schedule a nightly CLI run with cron

Add a cron entry to run the scenario every night at 2:00 a.m.:

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

This command:

1. Changes into the test directory.
2. Runs the selected scenario against environment 88.
3. Produces a JUnit report.
4. Appends output and errors to run.log.

You can also schedule the command through GitHub Actions. The JUnit output can then feed into existing CI reporting workflows.

For implementation details, see:

• Apidog CLI installation guide
• Apidog CLI in your CI/CD pipeline
• GitHub Actions schedule triggers
• cron

FAQ

Can I run scheduled tests on Apidog Cloud today?

Not yet. Apidog Cloud is marked “coming soon,” so use a self-hosted Runner for scheduled execution.

How often can scheduled tasks run?

The cadence is flexible, with examples such as every 6 hours or every Sunday at 11 PM. However, the number of scheduled runs is limited by your subscription plan.

How do I receive alerts only when a test fails?

In the task's Notification settings:

1. Select a channel: Slack, Teams, Webhook, Jenkins, or Email.
2. Choose the failures-only notification option.
3. Save the task.

This keeps channels quiet when tests pass and alerts the team when a failure occurs. Pair it with an API health check for a faster liveness signal alongside deeper regression coverage.

Why do scheduled results differ from local test runs?

Scheduled requests originate from the Runner machine, not your laptop. Its network, region, VPN configuration, and firewall rules can affect API responses.

Why do my variables reset after every run?

Enable Keep variable values on the test scenario design page. Without it, every scheduled run starts with fresh values.

Wrapping up

Scheduled tests turn “we think the API works” into “we know, and we would have heard if it did not.”

Start with this implementation checklist:

1. Build and validate your test scenarios.
2. Register a self-hosted Runner.
3. Create a scheduled task.
4. Select scenarios and an environment.
5. Set a run cadence.
6. Configure failure notifications.
7. Review Run History when alerts arrive.

For CI-driven scheduling, run the same scenarios with the CLI and schedule them with cron or GitHub Actions.

Download Apidog to set up your first scheduled regression suite.