September 29, 2026 · Ahmed · More by Ahmed
Shopify's Dev Dashboard Now Shows Custom Apps' Webhook Health
Shopify extended Dev Dashboard health monitoring to custom apps on Sept 25. Here are the concrete failure-rate and response-time numbers worth alerting on.
On September 25, 2026, Shopify extended the Dev Dashboard's app-health monitoring to custom (private) apps — previously this visibility was limited to public listed apps. Opening a custom app now surfaces its API request volume, error rates, webhook delivery health, and embedded admin page load speed, alongside a single filterable log stream covering every API request, webhook delivery, and app event, and a new home page that surfaces what needs attention across a whole app portfolio.
Why raw error rate isn't the right number to watch
The broader Dev Dashboard relaunch that this builds on makes a specific point about reading error-rate charts: a percentage alone is misleading without volume behind it. As Shopify puts it, "a 50% error rate across four calls is noise, but the same rate across forty thousand is an incident." Each error-rate chart in the dashboard plots the rate against request volume underneath it, and links directly into the Logs view pre-filtered to that API and to its failures — so a spike is one click from the actual failing requests.
The thresholds already exist — they're just newly visible
The new dashboard UI doesn't invent new benchmarks; it surfaces ones Shopify's webhook troubleshooting documentation has already defined for Classic Webhooks. A few are worth building alerts around directly:
- Failed delivery rate: Shopify's per-topic monitoring table calls a failed delivery rate over 0.5% "a higher-than-average failure rate," worth investigating per topic since a spike on one topic usually points to a handler- or payload-specific bug, while a high rate across every topic points to your backend not responding at all.
- Response time: the monitoring table reports response time as a 90th-percentile figure — 90% of responses at or faster than the listed number. The documentation separately flags four-to-five-second responses specifically, because Shopify's hard delivery timeout is five seconds; if you're regularly landing in that window, you're one slow dependency away from timeout failures.
- Retry and removal: Shopify retries a failed delivery up to eight times over a four-hour window. If it keeps failing, an Admin-API-created subscription is automatically removed and stops receiving deliveries until you recreate it — silently, unless you're watching for it.
Two habits worth adopting from Shopify's own guidance
Delivery ordering isn't guaranteed, within a topic or across topics for the same resource — Shopify's docs give the example of a products/update delivery arriving before the products/create for the same product. The fix is to order by the X-Shopify-Triggered-At header or the payload's own updated_at field rather than trusting arrival order, and to de-duplicate retried deliveries using X-Shopify-Webhook-Id.
Logs in the Dev Dashboard are retained for 30 days, with each filtered query window covering up to 7 days at a time — plan on stepping through multiple windows for anything longer. Between the new visibility into custom-app health and the failure-rate, response-time, and retry numbers Shopify already documents, there's now a concrete basis for deciding what "healthy" means for a webhook integration, rather than guessing.