- Admin API, App Shopify, Shopify Dev Dashboard, Sviluppo Shopify, Webhook
- Francesco Guiducci
Shopify Dev Dashboard 2026: how to monitor APIs, webhooks, and app performance
Shopify's Dev Dashboard has become the central place to understand whether an app is healthy before an error turns into a merchant-facing problem. With the September 25, 2026 update, Shopify brought app status, alerts, API request volume and errors, webhooks, Shopify Functions, logs, and embedded admin performance into the same environment.
The useful part is not simply having another dashboard. It is the ability to move from an aggregate signal — for example, a rising error rate — to the events behind it, filtering by type, shop, status, and time range. For anyone building or maintaining Shopify apps, that makes it easier to investigate the cause rather than only the symptom.
What the Dev Dashboard shows today
An individual app separates three areas that should not be mixed together: Operations for technical health, Admin performance for the experience of the app's pages inside the merchant admin, and Growth for data such as installs, uninstalls, and revenue when the user's role includes financial access.
For debugging, Operations is usually the most useful starting point. Shopify measures Admin API calls, webhook deliveries, and Function runs. Error rates are plotted against volume, so the same percentage means something very different across a handful of calls and across thousands of requests.
When a metric needs investigation, the Logs link opens the relevant event type already filtered to failures. That is the step that turns a chart into concrete evidence.
APIs: from error rate to the failed request
Logs can show GraphQL and REST requests with troubleshooting context including status, target, API version and, for GraphQL, query cost against the available rate limit.
One important detail: HTTP 200 does not automatically mean a GraphQL operation succeeded. Shopify's documentation explicitly recommends opening the entry and inspecting the operation response because GraphQL errors can exist even when the HTTP transport succeeded.
The API health tab also surfaces deprecated API usage. Its status reflects calls made with the app's access token during the previous 14 days, helping separate a future upgrade task from a deprecated call that is already occurring in real app traffic.
That report still needs context. Internal tools using the app token can affect the status too; for example, a deprecated call from a Postman collection can appear in the report.
Webhooks: what to watch before failures become an incident
For webhooks, Shopify shows volume, response time, failure rate, and individual deliveries. The documentation distinguishes a “High” chart indicator from the critical Webhook failures alert. The critical alert uses a stricter threshold: more than 0.5% of deliveries failing across at least 500 deliveries within 24 hours.
That threshold is not a target to approach. It indicates when Shopify considers failure levels serious enough to put webhook subscriptions at risk. Shopify retries failed deliveries, and persistent failures can eventually cause the subscription to be removed, which stops that topic from being delivered.
A practical investigation starts with the affected shop and the time the merchant reported the issue, then reads deliveries in sequence. This makes it easier to distinguish unreachable endpoints, response-code problems, and request-specific issues.
Admin performance is not backend speed
Admin performance measures three Core Web Vitals for the app's admin pages: LCP, INP, and CLS. They are measured in the merchant's browser, not on the app server.
That distinction matters. A fast backend cannot compensate for an embedded page that renders slowly, reacts late to input, or shifts elements while loading.
Shopify uses the same Core Web Vitals for Built for Shopify, but the dashboard card and the Built for Shopify assessment are not identical. Built for Shopify uses its own 28-day window and a minimum number of measurements, so the card's rating should not be treated as the final Built for Shopify verdict.
The log limits you need to know
Logs are useful, but they are not universal observability. Shopify retains them for 30 days, while a single query window can cover at most 7 days. On broad ranges, the table can also show a sample rather than every matching event, and the interface indicates when sampling is happening.
Large request and response bodies can be truncated. Some Function details can also depend on available scopes or access to the relevant shop.
The most important limitation is conceptual: Logs record what Shopify can see. A request made directly from a merchant's browser to your own backend does not necessarily pass through the systems represented there. An empty timeline, therefore, is not proof that nothing happened.
A simple debugging workflow
- Identify the shop and the time of the issue instead of starting from a global chart.
- Check alerts, especially deprecations, webhook failures, and Function errors.
- Open Operations to determine whether the pattern involves APIs, webhooks, or Functions.
- Drill into Logs and read the filtered events in order.
- Check what Shopify cannot see: your backend, database, queues, third-party services, and client-side browser activity where relevant.
- Finish with a real readback, not merely the fact that an error disappeared from the code.
The same principle applies when working with Shopify Functions and custom app logic: metrics and logs narrow the investigation, but the final verification still belongs to the real app behavior.
What the Dev Dashboard does not replace
The Dev Dashboard covers the parts Shopify can observe directly. It does not automatically replace your backend logs, database monitoring, third-party service errors, or your own alerting when an app includes infrastructure outside Shopify.
For a small Shopify app it can remove a lot of friction from platform-side troubleshooting. In a more complex architecture, it becomes one source that should be correlated with the rest of the technical evidence.
Why merchants benefit too
Merchants do not need to use the Dev Dashboard to benefit from it. The value is that the person maintaining the app can reach shop-specific evidence faster: a failed webhook delivery, a problematic API request, a Function error, or a performance regression inside the admin.
It is also a useful way to judge engineering method. A fix should not end at “the change was deployed.” It should end with evidence that the expected behavior works again in the real runtime.
The operational rule
Use the Dev Dashboard to narrow the problem, not to automatically declare the problem solved. Alerts, metrics, and logs are valuable evidence, but they have visibility limits and should be followed by a real verification of the affected function.
For Shopify app development, the September 2026 update makes that path more direct: fewer jumps between separate panels, and a clearer line from indicator to log to specific event.
