litespeed/run-crawler starts a crawl immediately instead of waiting for the schedule.
It reports that the run was dispatched. It never reports that a crawl finished, because on a large site that can be hours away.
At a glance
| Ability | litespeed/run-crawler |
| Toolset | LiteSpeed Cache — toolset/litespeed |
| Group | LiteSpeed Cache › The Crawler |
| Requires | LiteSpeed Cache, active on the site |
| Capability | manage_options |
| Safety | Writes data |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
Dispatched, not completed
The crawl runs asynchronously. Waiting for it would mean holding a request open for as long as the crawl takes, which is not a thing any caller wants and not a thing most servers permit.
So the contract is honest about what it knows: the run was started. Progress comes from polling litespeed/get-crawler-status, which reports position, count and the reason for the last stop.
A crawl warms the cache by visiting pages, and visiting pages costs exactly what a visitor costs. On a large site a crawl is a sustained load spike that the site’s real visitors share, which is why the load limit exists and why crawls are usually scheduled for quiet hours.
Which makes the timing of a manual run a real decision. Dispatching a crawl at peak hours adds load precisely when the site has the least to spare — and the benefit, a warm cache, arrives after the peak has passed.
The usual good reason for a manual run is after a full purge: the cache is cold, and warming it deliberately is better than letting the first visitor to each page pay for it.
Input
This ability takes no input.
What comes back
| Name | Type | What it is |
|---|---|---|
dispatched | boolean | Whether the run was started. |
note | string | A statement that completion is not reported here. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Warm the cache now — we just purged everything.
It resolves to one call:
{
"ability": "litespeed/run-crawler",
"parameters": {}
}Worth knowing
- Reports dispatch, not completion. Poll the status ability for progress.
- A crawl costs server load. Avoid peak hours.
- The best reason to run one manually is straight after a full purge.
- Not idempotent — dispatching twice starts two attempts.
Related abilities
- Get Crawler Status — poll for progress
- Reset The Crawl Position — start from the beginning
- Purge Cache — the thing that makes a warm-up worthwhile
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category