A scheduled condition-watch checks whether something has changed; it must not confuse repeated polling with evidence of a new event. Designing backoff and deduplication well can reduce cost, alerts and pressure on external services while preserving timely detection.
How it works
Model the watch as a stateful comparison with last observed value, last notified value, poll attempt, next permitted check and a source version. Use fixed or jittered exponential backoff for transient API failures and honor provider retry-after guidance. Keep the business notification trigger distinct from errors encountered while fetching the state. A failed poll should not automatically become a positive result.
A practical, bounded workflow
For a shipment-status watch, store the shipment identifier, verified carrier endpoint, last known status, last notification event ID and the next-check time. On each run, fetch status with authorized credentials, validate response freshness and compare it with the previous accepted state. Notify only on a meaningful transition, such as ‘out for delivery’ to ‘delivered’. If the API returns a throttling response, reschedule without wiping the last valid state.
Failure modes and limits
Clock-based scheduling can generate duplicate runs at daylight-saving changes or after worker restarts. Normalize internal timestamps to UTC while honoring user-local delivery windows separately. Use a lease so two workers cannot notify on the same transition, and retain an idempotency marker for the notification provider. Set a maximum lifetime: an abandoned watch should not poll forever.
Deployment controls
Assign responsibility for each transition: scheduled, running, awaiting evidence, awaiting approval, writing, reconciled, canceled or unresolved. The controller, not a free-form language response, decides whether a next action is authorized. Persist operation IDs and deadlines so a restart does not erase obligations or repeat committed effects.
When to choose this approach
Prefer native provider webhooks when they are authenticated and reliable, with reconciliation polling as a fallback. Avoid tight polling for low-urgency changes. A browser agent that reloads a site repeatedly is usually less robust than the service’s official status API.
What to evaluate before production
Simulate clock skew, daylight-saving shifts, 429 errors, repeated identical state, missed events and multiple workers. Verify the watch sends at most one notification per genuine transition and records when it lacked enough evidence to assert a change.
Version, market and tier caution (25 October 2026): This is a technical and operational guide, not a live entitlement, pricing or geographic-availability certification. Numeric commercial limits and undocumented release dates are intentionally omitted. Reconfirm the exact account, deployment region, access policy and vendor release before procurement or publication.