Scheduled Tasks and Automation
APIs don't only break when you change code. They break when the database disk fills up, when a 3rd party license expires, or when the network fluctuates.CI/CD protects you from bad code, but Scheduled Tasks protect you from bad environments.In Apidog, Scheduled Tasks allow you to run your Test Scenarios automatically at specific intervals.The Engine: Self-Hosted Runner#
Unlike some cloud-only tools, Apidog uses a Self-hosted Runner (General Runner) to execute scheduled tasks.Why Self-Hosted?#
1.
Security: The runner sits inside your network (or VPC). It can access your internal Staging/Dev databases and local APIs (localhost) that the public cloud cannot reach.
2.
Control: You manage the resources and environment dependencies (like database drivers or SSL certificates).
Setting up a Runner#
Before creating a task, you need a runner online.1.
Go to Settings (Team) > General Runner.
2.
Apidog provides a simple Docker command: 3.
Run this on your server (Linux/Mac/Windows).
4.
Once the runner status changes to "Started" in Apidog, you are ready to automate.
Creating a Scheduled Task#
Once your "Engine" (Runner) is running, you can tell it what to do.1.
Navigate to Testing > Scheduled Tasks.
1. Select Scenarios#
Pick the Test Scenarios you created earlier (e.g., "User Lifecycle"). You can chain multiple scenarios together in one task.This is a critical step. Since the task runs automatically, you must define:Environment: Which environment to test against (e.g., Staging).
Test Data: If your scenario relies on CSVs, ensure they are configured.
When running multiple scenarios, you need to decide how variables are shared:Share only in current scenario: Variables reset after each scenario.
Share across task: Scenario A can pass a {{token}} to Scenario B.
3. Set the Schedule#
Define when the "Engine" starts the car.Frequency: Every X minutes/hours, or specific days/times.
Cron Expression: For advanced users needing complex schedules (e.g., "Every weekday at 9 AM").
4. Notifications#
A monitor is useless if nobody sees the red light.Channels: Email, Slack, Microsoft Teams, DingTalk, etc.
Notify always: Good for daily reports.
Notify on failure: Anti-spam mode. Only bug you when something breaks.
Real Case: Production Health Monitor#
Let's set up a "Smoke Test" that runs every 15 minutes to ensure critical paths are working.1.
GET /public-status (Fast check)
2.
POST /auth/login (Critical dependency check)
Runner: "Prod-Monitor-Runner" (A runner deployed in the Prod VPC).
Schedule: Every 15 minutes.
Notification: Slack Channel #ops-alerts (Only on Failure).
Key Takeaways#
Scheduled Tasks turn tests into monitors.
Self-Hosted Runners allow you to test internal/private network APIs securely.
Use Notifications effectively to alert the right people without noise.
Ensure Variable Scopes are correctly set if chaining multiple scenarios.
What's Next#
We have covered the entire lifecycle from the first click to 24/7 monitoring. We have one final chapter to discuss advanced strategies like security and contract testing. Modified atΒ 2025-12-25 09:54:41
