API health
Check every five seconds. Fire after three server errors and recover after two nonmatching observations.
Build an HTTP watch →Examples / Persistent watches
Small watches.
Useful answers.
Each example uses a supported source and an explicit condition. Validate the manifest, try a fixture, and apply it to your daemon when you’re ready.
Start here · no external service
Your first firing.
Your first firing.
Your first recovery.
Push a latency reading above 300 ms, inspect the event, then send a lower reading to recover. Notifications print to your daemon’s console.
Follow the quickstart ↗One input. A recorded decision.
{"latency_ms": 350}
condition: latency_ms > 300
event: firing
delivery: console output
{"latency_ms": 100}
event: recoveredIllustrated outcomes; the guide shows authenticated requests.
Choose a source and a condition
A few good starting points.
Missing heartbeat
Record an incident when ten minutes pass without fresh input. A new observation recovers it.
Watch for missing data →A local status check
Run an explicit, trusted command returning JSON. Select the fields the condition needs.
Run a local check →A new version or event
Keep a typed baseline or deduplicate provider IDs within a declared horizon.
Recognize a change →Try it without source requests
Replay the failure.
Then the recovery.
The API-health fixture contains three 5xx responses followed by two 200 responses. Replay evaluates those recorded inputs without sending a notification.
Follow the fixture walkthrough →From a built source checkout
./ding test examples/watches/api-health.yaml \
--events testdata/watches/api-health.jsonl \
--json500502503200200
Bring your own data
Explicit inputs.
Inspectable behavior.
Sports, prices, flights, and traffic need a real feed and any upstream
calculations. Ding does not bundle provider access or invent an
integration.
Browse the documentation →