Scheduled automation

Scheduled automation runs a tool, a model, or a tool feeding a model, on a repeating schedule — and sends you the result. It is the difference between a tool you remember to open and one that tells you when something changed.

What a job is

A job has four parts, and only the first is required:

1. What to run — a tool with its settings, a prompt for a model, or both in sequence.
2. How often — from every minute to once a month, depending on your plan.
3. Where the result goes — email, a webhook to your own server, saved output, or nothing at all.
4. Limits — an optional monthly credit cap.

Start from a template, not a blank form

The gallery is the fastest way in. Pick an outcome, fill in one or two fields, save. A template is a copy: once your job exists it is entirely yours, and nothing we do to the template afterwards changes it.

Templates marked Verified have been run by us against a real provider and produced a real result. Unverified ones may still be good — they simply have not been proven yet.

What a run costs

Every run is billed exactly as if you had made the same call yourself, at the API price:

Two things are worth knowing:

• A failed run is never billed. It still appears in your logs, at zero credits, so "you were not charged" is something you can check rather than something we assert.
• A pipeline whose first step fails never runs the model, so you are charged for the fetch attempt only — never for a model call that had nothing to read.

Before you save a job, the form shows what it will cost per month at the interval you chose. That estimate is the reason most surprises do not happen.

Spend caps

Set a monthly credit cap on any job. When the job reaches it, the job pauses and you get an email — it does not keep running and it does not silently stop.

The cap stops the next run; it does not abort one already in progress. A run's real cost is not knowable until it has finished, so a cap enforced by prediction would either block runs that would have fit or let through ones that did not. Stopping at the boundary can overshoot by at most one run, and it is a rule we can state exactly.

Run now counts against the cap. A cap with an exception is still a cap you trust, which makes it worse than none.

When a job stops on its own

We pause a job rather than let it fail forever. What counts as "enough" depends on the kind of failure:

A timed-out website will very likely work in ten minutes; a stored setting that no longer parses will fail identically forever. Treating both as three strikes would either give up on the first too early or retry the second 1,440 times a day.

You get one email when a job pauses, and never one per failed run. A broken endpoint would otherwise flood your inbox and train you to filter us — and then the message that mattered, the pause, is the one you miss.

Resuming clears the pause and the failure count, and schedules the next run one full interval from now. It never fires immediately on resume.

Delivery

Email sends the result with the credits charged in the subject line, so a charge you were not present for is explained where you are already looking.

Webhooks POST JSON to your server. Every delivery is signed:

X-ToolsXpo-Signature: sha256=<hmac over "timestamp.body">
X-ToolsXpo-Timestamp: <unix seconds>
X-ToolsXpo-Run-Id:    <stable across retries>
X-ToolsXpo-Attempt:   <1, 2 or 3>

Verify by recomputing the HMAC over timestamp + "." + rawBody with your signing secret. The timestamp is inside the signature, so a captured payload cannot be replayed forever — reject anything older than your own tolerance.

Delivery is at least once. Use X-ToolsXpo-Run-Id to deduplicate; it stays the same across all attempts of one run.

Retries: 3 attempts at roughly 1 minute and 5 minutes, on 5xx and network errors only. A 4xx is not retried — that is your server saying "do not send this again". Redirects are not followed; point the job at the final URL. Timeout is 10 seconds.

Webhook URLs must be public HTTPS. Private addresses, loopback, cloud metadata endpoints and our own hostnames are refused.

Saved output

Switch on saving and each result is kept for a number of days set by your plan at the time the job was created. A later plan change never shortens what you have already collected.

Outputs appear under Saved outputs, where you can preview, download or delete them early. Deleting an output leaves the run in your logs — the record of what you were charged is not deleted with the data.

Pipelines

A pipeline is one fetch and one model call. The fetch runs, and its result is available to your prompt:

Summarise what changed. Be specific about pricing.
Ignore navigation and footers.

--- today ---
{{steps.fetch.output}}

--- last time ---
{{previous_run.output}}

{{previous_run.output}} is what makes change detection work, and it requires saved output — using it switches saving on automatically, because a diff against nothing is not a diff.

If the fetched content is larger than the model can accept, it is trimmed from the middle, keeping the beginning and the end, with a marker where the cut was. A page's beginning carries its headline and the end carries its footer and pricing; the middle is usually navigation.

Plan limits

Automation is not included in the free plan. A scheduler runs unattended and spends credits on every run, which is why it sits behind the plan boundary rather than being rate-limited into uselessness afterwards.

When storage is full, new output is not saved and nothing older is deleted to make room — you were told each result keeps for N days, and quietly shortening that would break the same promise a downgrade would. The run still succeeds, is still charged, and says in its log that nothing was stored.

Reading the logs

Schedule logs show every run: when, how long, what it cost, whether delivery landed, and an excerpt of what came back. skipped means we did not run it and did not charge you — a spend cap or an inactive workspace. lost means a run was interrupted and could not be completed; those are never billed either.