Executive summary
- What: the Developer Dashboard now reports how custom apps perform at runtime, not only how they are configured.
- Why: API request volume, error rate, webhook delivery health, and embedded page load speed are visible per app, each against a stated threshold.
- Who: Plus merchants running custom apps, and the internal teams or agencies that build and support them.
What changed
Opening a custom app in the Developer Dashboard now surfaces four measurements: API request volume, error rate, webhook delivery health, and the load speed of the app's embedded admin pages. Each is presented against a threshold, so a number reads as acceptable or not without you needing to carry a baseline in your head.
Alongside the metrics sits a single filterable stream containing every API request, webhook delivery, and app event. A new dashboard home page aggregates what needs attention across all apps in the organisation, ranking flagged items first. Merchants and the agencies or developers who build their apps see the same data, which matters more than it sounds.
Why it matters
Custom app failures are usually discovered downstream. Inventory stops syncing, a warehouse notices, and three parties then spend a day establishing whether the cause was a webhook that never arrived, a rate limit, or an application error. Webhook delivery health as a first-class metric collapses most of that diagnostic overhead.
Shared visibility is the more significant change for enterprise merchants. Support conversations about custom apps have historically opened with the merchant describing a symptom and the developer asking for evidence the merchant cannot produce. When both sides read the same event stream, the conversation starts at the cause. If you work with an agency, name this in your escalation process explicitly.
Thresholds deserve one note of caution. A stated threshold is a sensible default, not a judgement about your particular integration. An app pushing a large nightly catalogue sync will look nothing like one serving interactive admin pages, so expect to interpret the indicators rather than simply obey them.
Role-specific impact
- Marketers: indirect. Custom apps often power promotional mechanics or feed personalisation data, so failures tend to show up as campaigns behaving inconsistently rather than as visible errors.
- Developers: the filterable stream is the practical win. Filter to a failing webhook topic or an endpoint returning errors and work from evidence instead of reproduction attempts.
- Store admins: you can check whether a custom app is healthy before raising a ticket, and attach the relevant events when you do raise one.
Use-case example
Real-world scenario
A retailer's custom middleware pushes order data to a warehouse management system through a webhook subscription. Over a fortnight, roughly 2 percent of webhook deliveries fail and retry past the warehouse cut-off, so a handful of orders each day ship a day late. Nobody connects the pattern, because the orders do eventually ship. With webhook delivery health visible against a threshold, a 2 percent failure rate reads as degraded immediately, and the cause, a timeout on the receiving endpoint under concurrent load, is identified from the event stream in an afternoon rather than across weeks of anecdote.
Implementation checklist
- Confirm which custom apps your organisation owns and who maintains each one.
- Review the four health metrics per app and record a normal range, since your own baseline matters more than the default threshold.
- Grant your agency or internal development team dashboard access so both sides read the same data.
- Add webhook delivery health to whatever operational monitoring routine already covers integration uptime.
- Update your escalation process to require relevant event stream entries on any custom app ticket.
- Revisit the metrics after your next high-traffic event, when load-related failures are most likely to appear.
FAQ
Q: Does this replace our own application monitoring?
A: No. It reports what Shopify observes at its own boundary: requests received, webhooks delivered, pages loaded. Failures inside your infrastructure remain invisible here, so platform-side and application-side monitoring are complementary.
Q: Is this only for apps we built ourselves?
A: The performance view covers custom apps in your organisation. Third-party apps installed from the App Store are managed by their publishers, so you will not see this data for them.
Resources
Need guidance? Talk to Makro.