Automation & API · Set it and forget it
Cron Scheduling
Attach a cron expression to any connector and it runs unattended. You see it in plain English before you save, edits are picked up live, and every run is watched. Set it once and stop thinking about it.
Sideband0 */6 * * *:Every 6 hours0 2 * * *:At 02:00 AMlastError: 429 Too Many Requests; schedule kept, next run on cadence
0 7 * * 1-5:At 07:00 AM, Monday through FridayIllustrative. Every schedule carries its expression, its plain-English reading, and its next and last run.
Expressions
Cron you can read back
Expressions are Croner-compatible: standard UNIX cron, plus seconds, ranges, lists and steps. As you type, the schedule editor translates the expression into plain English via cronstrue and shows the computed next run. So 0 */6 * * * reads as "Every 6 hours" before you commit to it, and a typo never quietly runs at the wrong time.
Schedule expression
Every 6 hours
Next run: today, 18:00
Every 30 seconds
Next run: in 12 seconds
At 08:00 AM, Monday through Friday
Next run: tomorrow, 08:00
Croner-compatible: standard UNIX cron, plus seconds, ranges, lists and steps.
Live
Edits land within five seconds
The scheduler re-reads its schedules every 5 seconds. Change a cadence, pause a job or add a new one, and it gets picked up on the next pass. There is no restart, and no window where the schedule you saved and the schedule that runs disagree.
Inbound
Runs that apply their own results
An inbound schedule fetches and then applies. Results are matched to your parts by IPN or name and written back in the mode you chose: add for new parts only, sync to update what is already there. The library you open in the morning already has the night's work in it.
Octopart enrichment · run finished, applying
- RES-0603-100K matched by IPN sync
- CAP-0805-10U-25V matched by name sync
- TPS62840DLCR no match add
3 results applied; nothing left to review.
Outbound
Pushes that pace themselves
Outbound schedules push in throttled batches, so a large catalogue reaches the other end at a rate it can take, on the cadence you set, without anyone pressing the button.
Failures
A failing job keeps its schedule
Every schedule keeps its lastRun and lastError. When a run fails, the error is recorded on the schedule and the schedule stays. The next run happens on cadence, so a flaky upstream API costs you one cycle and recovers on its own.
- lastRun and lastError, stored per schedule
- The cadence holds, with no silent auto-disable
Maintenance
One job ships enabled
catalog-retention is built in and already running: it trims the change-data-capture log to the most recent 10,000 operations. That keeps the Altium delta feed honest. Clients consume compact deltas, and one that falls too far behind is told to re-snapshot so it stays consistent.
catalog-retention · change log
- #174,201 update CMP-001482 trimmed
- #174,202 update CMP-003311 trimmed
- most recent 10,000 kept
- #174,203 create CMP-009120
- #181,440 update CMP-000917
- #184,202 delete CMP-002054
- #184,203 update CMP-007731
Deltas stay compact; a client too far behind is told to re-snapshot.
Explore related features
Put every part on one data model
Download Sideband for Windows and give your whole team one source of truth. Free 30-day trial — no card required.
Stable · Windows · free
Cron Scheduling
— signal not yet locked —
We're still tuning this one in. Drop a reaction to boost the signal — the pages you react to most are the ones we finish first.
…or kill time while you wait:
Phasor toy
3.00 : 2.00 · locked