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 live run may be repaired automatically. This page also covers Changelog, the entry just above it, and the notes at the end of the statement of work.

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, Jason is asked to repair the pipeline after its latest live run fails. Saves as soon as you flip it; a failed save reads Could not save the auto-heal setting.

The note under the switch reads Timer and webhook failures can ask Jason to start a repair. Manual, CLI, UI, and Jason runs never do. It describes which failures ask Jason straight away. Other failed live runs, including one you started by hand, also leave the pipeline degraded, and Jason is asked to repair it about a minute later. See When a repair starts.

Turning it off stops Jason from being asked automatically. It does not interrupt a repair already under way, and it does not stop you from pressing Fix with Jason on a failed run. It also does not make a degraded pipeline runnable: the pipeline stays degraded, its banner reads Automatic healing is turned off., Autoheal now is hidden in the Changelog, and scheduled slots keep being skipped until a repair lands. Turn it back on, or use Fix with Jason, to get the pipeline running again.

Leave Enable Auto Heal on unless you want to decide every repair yourself. With it off, a degraded pipeline waits for you.

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

Versions, automatic repair attempts, and human decisions. A heal status card at the top (with Autoheal now while the pipeline is degraded), then a table with Event, Outcome, Summary and When columns. Click a row for its details, including View v<n>, which opens that version in a window where it can be restored. Every outcome and link is explained in Versions and changelog.

Notes

Standing instructions and gotchas. Jason reads these whenever it works on this pipeline. A plain text box at the end of the statement of work. 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