Settings reference

Settings is the last entry in the pipeline’s How it works rail. It holds the three things you change without asking Jason: when the pipeline runs, how long it may reuse pages it has already fetched, and whether a failed scheduled run may repair itself. This page also covers Changelog & Notes, the entry just above it.

Settings apply to the pipeline, not to a version. Changing them does not create a new version.

1. Schedulewhen runs start
2. Cachehow fresh sources must be
3. Advancedautomatic repair on failure

Schedule

Schedule decides when runs start on their own. The heading reads Configure when this pipeline runs automatically. The same editor opens when you click the schedule line in the statement of work.

Option	Values	Default	What it does
Cadence	Hourly · Daily · Weekly · Off	Off	Off means runs start only when you, a webhook or Jason start them. Choosing Hourly selects all seven days; Weekly starts with Monday, Wednesday and Friday.
Repeat interval (Hourly)	Every <n> hour(s), 1 to 24	1	How often a run starts on the selected days.
Days (Hourly, Weekly)	Mon … Sun toggles	Hourly: all; Weekly: Mon, Wed, Fri	The days runs may start. At least one is required.
Only run between set hours (Hourly)	Checkbox	Off	Limits hourly runs to a window. Reveals Start and End.
Start / End (Hourly, windowed)	Times	09:00 / 20:00	The window. End time is not included. — a 09:00 to 20:00 window with a 2-hour interval runs at 09:00, 11:00, … 19:00.
Time (Daily, Weekly)	Time	09:00	When the run starts on each selected day.
Timezone	A timezone; your browser’s zone is preselected	Browser zone	The zone every time above is read in. Daylight-saving changes follow this timezone automatically.
Preview	Text	—	A sentence describing the result, for example Every day at 09:00 · 7 runs/week or Every 2 hours from 09:00 until 20:00 on 5 days · 30 runs/week · Europe/London.
Next run in	Countdown and absolute time	—	Shown once a schedule is saved and the next slot is known.
Save Schedule	Button	—	Saves; reads Saved! for two seconds. Disabled while a field is invalid.

Validation messages appear under the fields: The interval must be a whole number from 1 through 24., Select at least one day., The end of the active window must be after its start.

Automatic runs only start while the workspace is live. An active run causes that scheduled slot to be skipped. If a run is still going when the next slot arrives, that slot is skipped rather than queued; the pipeline catches up at the following slot. A workspace that is out of rows or whose access is paused does not start scheduled runs at all. When access is paused the editor reads Workspace access is paused. Resume access to schedule collection. and only Off can be saved.

Time zones, what a scheduled run publishes and how to pause a schedule are covered in Scheduling.

Cache

Cache sets how long unchanged source requests may reuse a saved response. The heading reads Source freshness. A page fetched on Monday morning can be reused on Monday afternoon instead of being fetched again, which makes runs faster and lets a repaired pipeline re-run without re-reading every page.

Option	Values	Default	What it does
Source freshness	Off · 1 hour · 1 day · 7 days · 30 days · a custom duration	30 days (badge Default · Maximum)	How old a saved response may be before the page is fetched again.
Save Cache	Button	—	Saves; reads Saved. Disabled until you change something, and until the pipeline has its first version (Create the first pipeline version before changing its cache setting.).

The options in order:

• Off. Always fetch live. Individual requests cannot turn caching back on.
• 1 hour. A safe starting point for most pipelines.
• 1 day. Useful when source pages normally change once a day.
• 7 days. For stable pages that still receive occasional updates.
• 30 days. Best for published or historical pages that rarely change. This is the maximum: saved responses are never reused after 30 days whatever the setting.
• A custom duration Jason set appears as an extra option with the badge Current and the text This pipeline has a custom cache duration.

Two things to know:

• The pipeline can be stricter, not looser. A step that must always see the live page fetches live regardless of this setting, and a step may ask for a shorter freshness for a particular fetch. The setting is the ceiling used when the pipeline does not say otherwise.
• Applies to future runs immediately. Existing cached entries are not deleted. Shortening the duration does not throw anything away; it stops older responses being reused.

For one run you can ignore the cache entirely with Fetch live sources in the run dialog. See Running a pipeline.

A price pipeline that runs every morning at 06:00 wants 1 hour or Off: yesterday’s price page is exactly what you do not want reused. A pipeline that collects historical filings can sit at 30 days.

Advanced

Advanced holds one switch: Control what Jsonify does after this pipeline fails.

Option	Values	Default	What it does
Enable Auto Heal	On · Off	On	When on, a failed scheduled or webhook-triggered run asks Jason to start a repair. Timer and webhook failures can ask Jason to start a repair. Manual, CLI, UI, and Jason runs never do. Saves as soon as you flip it.

Turning it off stops future scheduled and webhook failures from opening a repair. It does not interrupt a repair already under way, and it does not stop you from pressing Fix with Jason on a failed run. What a repair looks like from your side is described in Verification and repair.

Settings Jason manages

Some behaviour that feels like a setting is part of the pipeline itself and is changed by asking Jason, so that it is versioned and reviewed like any other change:

• Default item limit. How many input rows each map step takes by default. Shown in the run dialog as Up to <n> items per map step and on cards as the default scope.
• How a dataset is written. Whether each run replaces the dataset or appends to it, and which key de-duplicates appended rows.
• Zero-row policy. Whether a run that produces no rows counts as a failure (the default) or may publish an empty revision.
• Site logins. Whether the pipeline may use saved logins for sites that need them.

Append each run to the dataset instead of replacing it, de-duplicated on retailer plus sku plus observed date.

Changelog & Notes

Changelog & Notes sits above Settings in the rail and has two tabs.

Changelog

Every version of this pipeline and why it was created. A timeline with one row per version: v2, a source badge (build, edit, Auto-heal, Manual heal), a current pill on the active one, how long ago it was created (hover for the exact time), and the changelog line. Hover a row for View, which opens that version’s statement of work. Versions are explained in Versions and changelog.

Notes

Standing instructions, gotchas, and a running changelog. Jason reads these whenever it works on this pipeline. A plain text box. Whatever you write here is put in front of Jason on every build, change and repair of this pipeline, so it is the place for things Jason cannot learn from the sources:

• 2026-07-11: switched to the retailer’s product feed; the listing page kept changing.
• Never request more than 100 items per page from the feed — it rejects larger pages.
• The client only cares about UK listings; ignore .ie and .eu variants.

Option	Values	Default	What it does
Notes	Free text	Empty	Saved on the pipeline, outside any version.
Saving	Saving… · Unsaved changes · Saved	—	Autosaves 800 ms after you stop typing and when you leave the box. ⌘S or Ctrl+S saves at once.

Notes are not shown to the reviewer as requirements; they are context. If something must always hold, ask Jason to make it a rule so it appears in the statement of work and is checked on every version.

What’s next