Quiet failure alerts for a custom Shopify checkout application

What was happening

The storefront used a Laravel application hosted separately from Shopify to validate promotion rules and create Draft Order checkout links. We needed a private signal when that handoff encountered an error, with no additional work on successful checkouts and no message sent for each customer retry.

Why the obvious solution was not enough

Calling the real checkout-creation endpoint as a synthetic availability check could create unwanted Shopify Draft Orders. A failed notification service also had to remain harmless to customers. And an error handler can only report failures it actually sees: if the entire application is unavailable before it can report, a separate external availability check is still needed.

How the solution works

1. Keep the storefront's existing checkout-error handler and customer-facing failure state. Add lightweight, best-effort reporting on that error path instead of changing normal checkout behavior.
2. Report relevant application-side failures from the Laravel service over an authenticated server-to-server channel. Keep its reporting secret on the server, never inside Shopify theme JavaScript.
3. Dispatch notifications without awaiting delivery on the customer's checkout path. A timeout or email-provider problem must not create another checkout failure.
4. Process reports in a separate Cloudflare Worker, validating the request before triggering delivery. Browser-originated signals and authenticated backend signals must not be mistaken for the same trust level.
5. Use an atomic Cloudflare D1 reservation for a shared 30-minute cooldown. A burst of reports should produce one alert window, not one email per request or shopper.
6. Forward an approved alert through a Google Apps Script email workflow to a single private technical inbox. Send only the minimum diagnostic context, not customer details, payment information, or cart contents.
7. Check the report endpoint, unauthorized-request rejection, delivery to the intended inbox, and repeated-report suppression with controlled test signals. Inspect application reachability separately using GET-only requests.

What should be verified before shipping

• Confirm a successful checkout path does not send a failure notification.
• Confirm the backend report requires valid authentication and an unauthorized request is rejected.
• Send a controlled test report and verify delivery only to the intended private inbox.
• Send concurrent or repeated reports and verify the shared cooldown prevents duplicate emails.
• Check the storefront's existing error state and the application's response handling remain unchanged if reporting fails.
• Use GET-only service diagnostics instead of synthetic Draft Order creation.
• Before claiming complete coverage, test a controlled real checkout failure and add independent outage monitoring for cases when an error handler cannot report.

What changed

The Worker, D1 cooldown, and private email delivery were exercised with controlled reports. An unauthorized report was rejected, and the reporting route was verified without creating test Draft Orders. The theme integration and application service were also checked. A real end-to-end checkout failure was not deliberately triggered, so this is verified alert plumbing, not proof that every outage will be detected.

Reusable lesson

An alert should observe the transaction, not become a dependency of it. Report only meaningful failures, isolate notification infrastructure, centralize deduplication, and state exactly which failure modes still require independent monitoring.

How I would evaluate this today

Client identity and operational endpoints are deliberately omitted. This describes targeted error notifications, not an uptime SLA, full end-to-end checkout monitoring, or payment processing by the alert service.