For the jobs that should not need
your laptop to be open
Everything Fyre does locally, it can do on a schedule. Build the recipe in the side panel where you can see what you are selecting, then promote it — same selectors, same transforms, no rewrite.
Six things a scheduled run has to get right
Automation is easy to start and hard to trust. These are the parts that decide which one you have.
Real browsers, not fetch
Every run executes in a full browser. JavaScript renders, lazy images resolve, and the cookie wall gets dismissed before extraction starts — because a run that returns a consent banner is not a run.
Intervals that make sense
From every ten minutes to once a month, in your time zone rather than UTC. Overlapping runs are skipped instead of queued, so a slow Monday cannot pile up behind itself.
Parallel workers
A 4,000-page job splits across workers instead of walking the list one page at a time. You set the concurrency; the default is deliberately polite.
Straight into a sheet
Create a new sheet per run, replace the contents of one, or append with a run-timestamp column. The people who need the data never have to touch a download folder.
Or into your own stack
POST the batch to your endpoint as JSON, with retries, a signed header and a delivery log you can read when something downstream swallows a payload.
Told when it breaks
Set a minimum row threshold. If a run comes back thin — the usual sign a site changed its markup — you get an email instead of a sheet quietly overwritten with blanks.
Build it where you can see it. Run it where you cannot.
The reason cloud scrapers are miserable to configure is that you are writing selectors blind against a page you are not looking at. Fyre inverts that: you click the fields on the real page, confirm the columns, and only then send the recipe upstairs.
- 1Build and test the extraction in the side panel until the columns are right.
- 2Choose 'Promote to cloud'. Selectors, pagination and transforms travel with it.
- 3Pick an interval, a page cap and a destination.
- 4Set the alert threshold so a broken site emails you instead of silently succeeding.
- Competitor catalogueMondays 07:00 · Sheets · replace2,481 rows
- Marketplace pricesEvery 6 hours · Webhook914 rows
- Job board — EU remoteDaily 06:30 · Sheets · append0 rows
A run has to end somewhere useful
Downloading a CSV from a dashboard is not automation, it is a chore with extra steps. Cloud runs deliver: into a Google Sheet the team already has open, or into your own endpoint with a signature you can verify.
- Google Sheets — create, replace or append, with the run timestamp as a column.
- Webhook — batched JSON, exponential-backoff retries, HMAC signature header.
- Storage — the last 30 runs stay downloadable as CSV from the dashboard.
{
"run_id": "run_8b21f0",
"recipe": "competitor-catalogue",
"finished_at": "2026-08-17T06:04:11Z",
"pages": 62,
"rows": 2481,
"schema": ["title", "price", "sku", "in_stock", "url"],
"data": [
{ "title": "Kestrel Trail Runner",
"price": 89.0, "sku": "KTR-42",
"in_stock": true, "url": "https://…" }
]
}What the cloud costs, and what it does not
Local extraction is unmetered and always will be — it runs on your machine, so there is nothing for us to charge for. Cloud runs execute on our infrastructure, so the licence includes a monthly page allowance rather than an unlimited one. The allowance is generous for the scheduled-monitoring work most people use it for, and you set a hard cap so a run can never quietly exceed it.
Because runs happen on our side, cloud jobs are the one place where page content touches our servers. Results are held for 30 days so you can re-download them, then deleted. You can shorten that window, or set it to delete on successful delivery, in the run's settings. The privacy page spells out exactly what is stored.
Set it once. Read the sheet on Monday.
Scheduled runs are part of the same one-time $15 licence — no separate cloud plan to sign up for.