Put any developer tool on a schedule. Get the answer, not the data.
Scrape, resolve, inspect and check — then hand the result to a model that tells you what changed and whether it matters. 230 tools, no server to run, and a retry that never charges you twice.
Automation is included from the Pro plan upward. A free account gets you the tools and the API.
230
schedulable tools
3–200
jobs, by plan
10
sources per job
0
servers to maintain
The problem
Everyone ends up owning a cron box
It starts as one script. Check the certificates. Then a second — watch that page. Then a third, and now there is a small server nobody wants to own.
The scripts are not the hard part. The hard part is everything around them: the machine they run on, the patching, the alerting when the alerting breaks, and the quiet week in which a job stops working and nobody notices because a scheduled task that fails silently looks exactly like a scheduled task with nothing to report.
The alternative most teams reach for is a general automation platform, and the sticker price looks fine until you multiply it. Zapier bills per step. A five-step job running ten thousand times a month is fifty thousand billable tasks, not ten thousand — depth is a multiplier. n8n bills per execution, which is far kinder arithmetic, and self-hosting removes the licence cost entirely. What it does not remove is the server, the upgrades and the pager.
There is also a fit problem. Those platforms are built to connect business applications, so the developer work — resolve this record, read that certificate, parse this response — arrives as a generic HTTP block and a pile of glue. Here the tools are the product. All 230 of them are schedulable, with their own inputs, and nothing to configure before the first run.
How it works
A source, a question, and somewhere to send the answer
Two steps is the whole design. Every use case we researched fits in one fetch and one interpretation; a third step multiplies the cost and the failure modes for cases nobody asked for.
- 1
Pick what to run
Any of the 230 API tools, with its own inputs — a domain, a URL, a record type. Or point one job at up to ten sources and fetch them in parallel.
- 2
Say what you want to know
A prompt in plain English. It can reference the fetched output, and the previous run's, so “what changed since yesterday” is a question you simply ask.
- 3
Choose where it lands
A signed webhook, an email, or stored output you read later. The run keeps every step's timing, spend and result.
What people automate
The jobs that keep getting written by hand
Each of these is a tool that already exists here, a schedule, and a delivery address. None of them needs a server.
SSL certificate expiry monitoring
Check every domain you own on a schedule and hear about it weeks before a certificate lapses — not from a customer on a Sunday.
Website change detection
Scrape a competitor's pricing page each morning and get told only when the number moves. The diff is against yesterday's fetch, not yesterday's summary.
DNS drift and propagation
Resolve the records that matter and get alerted when one changes underneath you — a registrar edit, a stale cache, a failed migration.
Security header audits
Run a header and CSP audit against your own domains weekly, so a deploy that quietly drops a policy does not go unnoticed for a quarter.
Broken link and status sweeps
Walk a list of URLs on a schedule and receive only the ones that stopped answering.
Feed and release digests
Pull a changelog or feed, have a model condense it, and read three lines instead of forty items.
API key and secret rotation checks
Verify that credentials still authenticate before the thing that depends on them discovers otherwise in production.
Competitive briefs from many sources
Point one job at up to ten pages and get a single merged brief, with each source labelled so nothing is attributed to the wrong company.
Anything else on the API
All 230 tools are schedulable. If you can call it, you can put it on a clock and have the result delivered.
Learn moreCompared
Against what you are probably doing instead
Billing models rather than prices — a published price goes stale, and the model is what actually decides your bill at volume.
| Capability | ToolsXpo | Zapier | n8n (self-hosted) | Your own cron box |
|---|---|---|---|---|
| Billed byThe single decision that sets your bill at scale | Credits consumed | Steps (tasks) | Executions | Server + your time |
| A 5-step job costs 5×Per-step billing multiplies with workflow depth | ||||
| Infrastructure to maintain | ||||
| Developer tools built in230 of them, no connector to configure | ||||
| AI interpretation step | ||||
| Retry reuses paid-for work | ||||
| Automatic refund on failure | ||||
| Per-job spend cap | ||||
| Runs without you patching it |
ToolsXpo
- Billed by
- Credits consumed
- A 5-step job costs 5×
- Infrastructure to maintain
- Developer tools built in
- AI interpretation step
- Retry reuses paid-for work
- Automatic refund on failure
- Per-job spend cap
- Runs without you patching it
Zapier
- Billed by
- Steps (tasks)
- A 5-step job costs 5×
- Infrastructure to maintain
- Developer tools built in
- AI interpretation step
- Retry reuses paid-for work
- Automatic refund on failure
- Per-job spend cap
- Runs without you patching it
n8n (self-hosted)
- Billed by
- Executions
- A 5-step job costs 5×
- Infrastructure to maintain
- Developer tools built in
- AI interpretation step
- Retry reuses paid-for work
- Automatic refund on failure
- Per-job spend cap
- Runs without you patching it
Your own cron box
- Billed by
- Server + your time
- A 5-step job costs 5×
- Infrastructure to maintain
- Developer tools built in
- AI interpretation step
- Retry reuses paid-for work
- Automatic refund on failure
- Per-job spend cap
- Runs without you patching it
Zapier and n8n are good products and this is not a claim otherwise. Zapier connects business applications faster than anything else; n8n, self-hosted, is the most capable engine of the three if you have somebody to run it. The distinction drawn here is narrow and specific: what you are billed for, and who owns the machine.
Built for 04:00
Scheduled work fails differently, because nobody is watching
An interactive tool that breaks gets a bug report in minutes. A nightly job that breaks gets discovered a fortnight later, by accident. These are the guarantees that matter when nobody is looking.
A retry never re-charges the fetch
The expensive half of a job is fetching. When a model step fails and retries, it is handed the pages already fetched — from durable storage, not a second scrape. You pay for a page once.
A failed step costs nothing
Credits are reserved before work runs and returned when it does not complete. A provider timing out at 04:00 is our problem, not a line on your bill.
One firing, one charge
Each run carries an id that is the primary key of its record. A redelivered message cannot execute a second time, whatever the queue does underneath.
A cap that actually stops
Set a monthly credit ceiling per job. Reaching it pauses that job and emails you, rather than continuing quietly and explaining afterwards.
Failures are loud
Repeated failures pause the job and tell you why. A scheduled task that silently stopped working months ago is the worst outcome available.
Every run is itemised
Each step's credits, duration and output are recorded. A surprising number always has a cause you can find.
In detail
Why a retry does not cost you twice
A pipeline job has an expensive half and a fragile half, and they are not the same half. Fetching is expensive: a dozen sources is a dozen billed calls. The model step is fragile: providers time out, rate-limit, and occasionally return nothing usable.
Handled naively, those two facts combine badly. The model fails, the run ends, the fetch is charged — correctly, it did the work — and you got nothing for it. The next scheduled firing then fetches all twelve pages again and charges again. On an hourly job against a flaky provider, that is paying repeatedly for the same pages and receiving nothing.
So the two stages run as separate durable steps. The fetch result is persisted, and a retried model step is handed that stored result rather than running the fetch again. The pages are not re-read and you are not re-charged. Retrying is safe to do willingly because a failed model step already refunds its own reservation — an attempt that fails costs nothing at all.
None of this is visible when it works, which is rather the point. It shows up as an absence: the bill that did not arrive, and the run that finished on the second attempt without mentioning the first.
Automation questions
How is this different from Zapier?
Mostly the billing model, and it matters more than the sticker price. Zapier bills per step, so a five-step job running ten thousand times is fifty thousand billable tasks. ToolsXpo bills for the work actually done in credits, so the same job costs what its steps cost — depth is not a multiplier. Zapier is also built for connecting business apps; this is built for running developer tools, and the tools are already here rather than being connectors you configure.
How is this different from n8n?
n8n is excellent and, self-hosted, is free of licence cost. What it is not free of is operations: you run it, patch it, monitor it, and get paged when it stops. That is a fair trade if you already have a platform team. If you do not, the cheapest automation is the one with no server attached to it.
Is this an uptime monitor?
No, and it would be a poor one. Dedicated uptime tools check from many regions with escalation policies and on-call rotas, and you should use one for that. This is for the other jobs — run any of the tools on a schedule, interpret the result, and deliver an answer.
How often can a job run?
It depends on your plan. Pro and Max schedule down to every five minutes, Ultimate and organisation Business down to every minute, and Enterprise down to every thirty seconds. Every job also gets a random offset inside its interval, so the platform's hourly jobs do not all fire at the same instant and hammer the same upstreams.
What happens if the page I am watching is down?
With one source, that is a failed run and the model step is skipped rather than being asked to summarise nothing. With several sources, one being down does not fail the job — the model is told which sources were missing, so it cannot silently imply it read everything.
Can one job watch several pages at once?
Yes, up to ten sources in a single job. They are fetched in parallel, so twelve pages take about as long as one, and the results are merged under labelled headings so a fact from one competitor is never attributed to another.
Where does the output go?
A signed webhook your server can verify, an email, or stored output you read later. Stored results live in object storage with a retention window set by your plan.
What stops a runaway job from emptying my balance?
A monthly credit cap per job, which you set. Reaching it pauses that job and emails you. Reservations are also checked before each step, so a job cannot spend a balance that is not there.
Do I need to know how to code?
No. A job is a tool, its inputs, a schedule, and somewhere to send the result. The prompt for the interpretation step is plain English.
Is automation included in the free plan?
No — automation starts at Pro. A free account gets you the browser tools, the API and monthly credits to try it with, but scheduled jobs need a paid plan. Pro includes three jobs at a five-minute floor, and the higher plans raise both.
What can I do without paying anything?
Rather a lot. All 209 browser tools run with no account at all, and a free account adds monthly credits for the API plus saving in the super tools. Automation is the line where a plan starts.
Start with one job
Pick a tool, pick an interval, and see what arrives tomorrow morning. Automation starts on Pro at three jobs; you can raise the cap once it has earned it.