Checkout failure alerting via polled logs and error APIs, with rollback kept separate

The article describes a checkout failure alerting design that polls logs and an errors API and evaluates the evidence in a shadow decision process before any action. Each checkout carries an operation ID through payment and reservation commit, and a poller normalizes records, saves source cursors, and checks a rolling window. Qualifying decisions produce durable alerts with idempotency keys, while an operator or separate controller verifies current reservation and payment state before any rollback. The author stresses that detection and control must stay separate, and that exception counts should never trigger rollback directly. The evidence contract is kept minimal, excluding guest names, addresses, payment data, and access tokens, and the decision threshold is passed in as a policy argument.