Quick Start
1
Just enable it
Incidents ride on top of the scheduler notepad, so the wrapper attaches the tracker automatically when you run from the scheduler.
2
Drive ticks yourself
Use the pure tracker when you drive ticks (custom runner, tests, out-of-process cron).
3
Tolerate transient blips
How It Works
The scheduler loads per-job state, runs the tick, folds the resultingRunRecord through the tracker, and delivers only when an alert is due.
What Counts As “The Same” Failure
Failures collapse to one incident when theirerror_signature matches, and normalise_error strips only the volatile parts of a message before hashing.
The normaliser then keeps a prefix of the first 200 chars and
sha256s it.
Tolerating Transient Blips
Setafter_failures=N to alert only when the same failure repeats N ticks in a row — a single flaky tick that recovers never pages you.
A blip that recovers before the threshold never alerted, so it sends no recovery note either.
Wiring the Alert
The returnedIncident carries the raw error for the alert body; hand it to the job’s existing delivery target — there is no new delivery API.
Configuration Options
IncidentTracker takes one option.
Each incident is a small dataclass persisted per job.
Full SDK reference
Fields, serialization
Common Patterns
Persist tracker state through the store you already use for the notepad — the incident dict round-trips as-is.Best Practices
Reuse the job's delivery target
Reuse the job's delivery target
Send incident alerts through the same
DeliveryTarget the job already uses — don’t set up a second channel.Keep after_failures low for daily jobs
Keep after_failures low for daily jobs
Use
1 or 2 for hourly/daily jobs. A high threshold delays detection because it needs that many consecutive ticks first.Keep the tracker at the runner level
Keep the tracker at the runner level
Don’t call
IncidentTracker from inside an agent tool — it’s a runner-level concern. The scheduler wraps it for you.Round-trip state through the existing store
Round-trip state through the existing store
Persist incident state through the same store you use for the job-state notepad, not a new one.
Related
Where the alert is delivered
The state store incident data rides on

