Scheduled Tasks

Document version: 20260905

App versions covered by this document:

iOS: >= 3.16

Android: >= 1.8.0

macOS / Windows (desktop): >= 1.0.21

A scheduled task can fire a Request Replay or a full Combo Replay rule on a Cron expression or a fixed interval. Use it when a human tap is too slow: flash-sale load tests, go-live checks, or periodic health probes.

Typical case: a flash sale lasts a few seconds, so tapping by hand usually misses it. Pull the place-order request from capture history (or build a Combo Replay), create a scheduled task, fire it every second just before the sale opens, and stop automatically when the body says success or “sale ended”.

Combo Replay orchestration, dependency injection, and expressions are covered in the Combo Replay guide.

Overview
Quick start
Where to find it and how to manage jobs
What a job runs
Schedule
Auto terminate
When it actually runs
Execution history and stats
Example scenarios
FAQ

1. Overview

Capability	What it does
Request Replay	Replays one HTTP/HTTPS request from a snapshot (method, URL, headers, body)
Combo Replay	Runs a whole combo rule from a snapshot (layers, expressions, parameter mappings)
Cron	6-field expression (seconds included): `second minute hour day month weekday`
Custom	Repeats every N seconds; you can cap run count and duration (iOS / desktop also have a start time)
Auto terminate	Two kinds only: regex on the response body, or exact string match on a JSON field. A hit disables the job; it does not pause it
Execution history	Its own Execution History panel, with Avg / P95 / P99 and success rate

2. Quick start

Capture traffic first so you have the HTTP/HTTPS request you want on a timer. For a multi-step flow, build and save a Combo Replay rule.
Open the Scheduled Task list and tap + / Add Scheduled Task.
Fill in Job Name and pick a target:
- Request Replay: pick one request from history. You can still edit query, headers, and body.
- Combo Replay: pick an existing combo rule. You can still edit each node’s request parameters.
Choose Cron or Custom, and check that the next-run preview on the settings page looks right.
Optionally turn on Auto Terminate and match a “success / finished” response with regex or a JSON field.
Leave the job Enabled, then:
- iOS / Android: start capture (VPN). Nothing runs until capture is on. While capture is running, those requests land in request history, and rewrite rules / scripts apply.
- Desktop: keep the ApiCatcher window open. No VPN required. Start capture only if you want rewrite / scripts to apply to the traffic the job sends.
Open the job to inspect Execution History.

3. Where to find it and how to manage jobs

3.1 Opening Scheduled Task

Capture home, top-right + → Scheduled Task
On the Request Replay or Combo Replay execute page, tap the alarm button in the top-right to create a job from the current request or rule

3.2 Create / edit / delete / enable

Action	How
Create	+ in the list, or Add Scheduled Task on the empty state
History	Tap the row
Edit	Swipe left → Edit
Delete	Swipe left → Delete (execution history for that job is removed too)
Enable / disable	Enabled toggle on the edit page

New jobs are enabled by default.

When you edit an existing job you cannot change the target type or pick a different request/rule. You can still change the name, the enabled switch, snapshot parameters / node parameters, the schedule, and auto-terminate conditions.

4. What a job runs

There are only two targets:

Job target	What runs
Request Replay	One HTTP request; expression injection is supported
Combo Replay	Several HTTP requests, in the order defined by the combo rule; dependency injection and expression injection are supported

If you change a Combo Replay rule and want the job to pick up the change, you must create a new job.

5. Schedule

Two types: Cron / Custom.

The settings page previews the next few run times (up to 5).

5.1 Cron

The expression has 6 fields, in this order:

second  minute  hour  day  month  weekday

A 7th field (year), if present, is ignored. Fewer than 6 fields means the next run cannot be computed, so the job is not scheduled.

This is not Linux crontab’s 5-field form. */5 * * * * (every 5 minutes) is invalid here.

What you can write:

*: any value in that field
?: on day or weekday, meaning “unspecified”
A single number: e.g. second 0, hour 9
Step / in the seconds field: 0/30 means every 30 seconds

Default / placeholder:

0 * * * * ?

That is: second 0 of every minute.

Examples:

Expression	Meaning
`0 * * * * ?`	Second 0 of every minute
`0 0 * * * ?`	Minute 0, second 0 of every hour
`0 0 9 * * ?`	09:00:00 every day
`0/30 * * * * ?`	Every 30 seconds

For “every N minutes”, use Custom and set the interval to N × 60 seconds.

You can generate a Cron expression from plain language with the AI control next to the field. After that, check the preview times.

An empty expression, or one that never yields a next time, means this job is skipped for now. It is not auto-disabled for that reason.

5.2 Custom

There is no separate end-time field. The job repeats on a fixed interval and stops when either the run count or the duration is reached (checked before each run).

Field	Unit	Meaning
Interval	seconds	How often it runs; at least 1
Max executions	times	Stop after this many runs
Duration	minutes	Stop this many minutes after the first run

Count and duration live in engine memory. They reset if the process restarts. A job that was already disabled stays disabled. Turning Enabled back on starts the count from 0.

When the count or duration is hit, the job is saved as disabled.

6. Auto terminate

UI name: Auto Terminate. Once a condition hits, the job stops even if Cron still has future ticks or custom runs remain.

Only two condition types. There is no “stop on HTTP status”:

Type	Matches	Rule
Regular expression	Response body text	A match anywhere in the body is enough (the whole body does not have to equal the pattern)
JSON field	Response JSON	Value at the path must be an exact string equal to Match value

Notes:

Several conditions are OR: any one hit stops the job.
Combo Replay can pick an observer node; only that node’s result is checked.
JSON compare is string equality: number 200 needs match value 200; booleans are true / false.

A hit disables the job. The job and its history stay; nothing is deleted.

7. When it actually runs

OS limits differ, so each platform runs the engine in a different process.

iOS

The job runs inside the VPN process. Capture must be started before anything fires.

Situation	Keeps running?
Capture on, main app in background	Yes
Capture on, main app swiped away, VPN still up	Yes
Capture stopped	All timers cancelled; stops
System reclaims the VPN process (memory)	Stops; start capture again to reload enabled jobs
Capture off	Does not run. Saving only writes the job; it is scheduled the next time capture starts

Request timeout is 15 seconds. With VPN on, replay goes through local MITM (127.0.0.1:8888), so rewrite rules and scripts apply, and the same traffic may show up in capture history.

Android

The job runs inside the VPN service. Capture must be started first.

Situation	Keeps running?
Capture on, app only sent to background (foreground notification still visible)	Usually yes
Capture stopped	`stop()`; coroutines cancelled; in-memory count / first-run time cleared
Force-stop the app	VPN and process die; jobs stop
System kills the process to save battery	Stops; if the foreground service is restarted and `start()` runs again, still-enabled jobs are rescheduled

Connect and read timeouts are 30 seconds each. Traffic also goes through local MITM, so scheduled replays can appear in capture history.

Desktop

Jobs run in the app process. They run as long as that process is alive, and stop when you quit.

Situation	Keeps running?
Window open (may be minimized)	Yes
Capture off	Yes
Quit the app	Stops

Single-request timeout is 30 seconds; each Combo Replay node is 5 seconds. Requests use the system proxy. If local capture is on, rewrite rules and scripts apply, and the traffic may show up in capture history.

Combo Replay execution (same on all platforms)

Layers follow the dependency graph; nodes in one layer run in parallel; the next layer waits.
If a node is not 2xx (or the send fails), later layers are skipped (no request).
Expressions, dependency injection, and global variables from the snapshot all run.

8. Execution history and stats

Tap the job to open Execution History (not the editor).

The stats header aggregates every run of this job (one timer fire = one row, not one HTTP request):

Avg / P95 / P99: duration of each run (that record’s end time − start time), then average and 95th / 99th percentile over all records, shown in milliseconds
Success Rate / Success / Failure: a run counts as success only if every request in it succeeded; one failed Combo Replay node fails the whole run. Those outcomes are then counted across all records

Tap a row to see the request that was sent. For Combo Replay you get the node list first, then tap a node for details.

The top-right control clears all history for this job. Deleting the job deletes the history with it.

This data lives in its own table, not the main History / Request History list. As in the previous section, the same traffic often also lands in main history while capture is on.

Those main-history rows are not tagged as scheduled tasks; they look like ordinary captures.

9. Example scenarios

Scenario 1: hammer the order API before a flash sale

Capture the place-order API and confirm body / headers (for a live timestamp, put ${method.timestamp()} on a Combo Replay node).
Create a scheduled task targeting that request or combo rule.
Custom: start a few seconds before the sale (must be in the future), interval 1 second.
Auto terminate: JSON field code equals 200, or a regex for "order placed" / "sale ended".
iOS / Android: start capture ahead of time. Desktop: leave the window open.

Scenario 2: ping a health check every minute

Cron works on all three platforms:

0 * * * * ?

Skip auto terminate. The job keeps running every minute until you disable it, or you stop capture (mobile) / quit the app (desktop).

Scenario 3: timed regression of login plus a business API

In Combo Replay, wire login → business API and inject the token.
Create a scheduled task from that rule.

10. FAQ

Q: I saved the job but nothing runs.
A: On iOS / Android you must start capture. On desktop the app must stay open. Also check that the job is Enabled, the Cron has 6 fields, and the preview can compute a next time.

Q: A custom job flips to disabled as soon as I save it.
A: A start time in the past makes the engine disable the job without running it even once. Set a future time, enable it, and save again.

Q: I edited the Combo Replay rule; the scheduled task did not change.
A: Expected. The job keeps the snapshot from when it was created. Delete it and create a new one.

Q: Why do these requests also show up in main history?
A: On mobile, with VPN on, scheduled replay goes through local MITM and is stored like any other capture. Use the job’s Execution History for the dedicated report. Main history has no scheduled-task badge.

Q: I set auto terminate to status 200 and it never fires.
A: There is no “stop on HTTP status”. Use a JSON field (e.g. code == 200) or a regex on the body.

Q: Why were some combo nodes never sent?
A: Same as a manual Combo Replay: after a non-2xx in an earlier layer, later layers are skipped. A skipped observer node has no body, so auto terminate will not match.

Q: Do jobs survive uninstall / clearing data?
A: Jobs and history are local. Uninstalling or clearing data removes them.

Q: Do I have to leave rewrite rules on?
A: On mobile, scheduled requests go through MITM. If a mock / drop / modify rule matches those URLs, that is what the job actually sends. When a response looks wrong, check rewrite and scripts first.