Shopify app logs: a Dev Dashboard support guide

When a Shopify app stops doing what you expect, give its developer a precise time, the affected store and an example of the failed action. Shopify’s Dev Dashboard can help the app team investigate, but it is only one part of the evidence.

Shopify’s 25 September 2026 announcement brought filterable logs and health metrics for custom apps into the dashboard, including request volume, errors, webhook health and embedded admin page speed. This guide explains how to use that development in a support conversation; it is not a new launch announcement.

What the app team can check

According to Shopify’s monitoring documentation, developers can narrow logs by shop, time, event type and status. The timeline includes API requests, webhook deliveries and Function runs. Logs are retained for 30 days, with a maximum seven-day range per query.

A broad query can return a sample, so the team should narrow the filters before concluding an event is missing. The dashboard also cannot see a browser request sent directly to the app’s own backend. An empty result does not establish that nothing happened; the developer may need its own server records.

Send a support report that can be investigated

Our recommended checklist is deliberately short:

• Identify the action. Describe what you expected and what actually happened. “The order was created but the warehouse did not receive it” is more useful than “the app is broken”.
• Record the time and time zone. Include the earliest known failure and a recent example. Avoid waiting until the next monthly review.
• Give one traceable example. Share the relevant order or task reference through the vendor’s private support channel. Include a screenshot of the visible error if there is one.
• Describe the scope. Say whether every attempt fails or only certain products, orders or users. Note any configuration changes immediately before the issue.
• Ask for an outcome. Request confirmation of where the failure occurred, whether affected work will be retried and how the fix will be checked.

These are editorial recommendations for organising a support request, not a guarantee that the dashboard will identify every fault. Keep customer details and access credentials out of public screenshots.

Confirm recovery with a real example

After a fix, repeat the affected workflow with the app team and check the intended business result. For an order handoff, that means checking the receiving system as well as the store. Keep the support reference and agreed follow-up together so the next person investigating has a starting point.

Shopify’s dashboard introduction also describes portfolio alerts and app-level monitoring. The official image accompanying this guide shows its Logs interface with example data; it is not evidence of an incident at a particular merchant.

If an unsupported-app warning remains

Shopify’s current API versioning guidance, checked on 18 October 2026, says admin warnings remain until seven days after the last detected use of unsupported resources. A warning therefore needs to be investigated alongside the timing of the calls, not only the date a developer shipped a fix.

The same guidance says calls are attributed to the app whose access token made them. A support tool using that token can raise an alert against the app too. Ask the developer to check all callers rather than assuming the latest deployed application is the only source.

Developers can also compare the requested API version with the X-Shopify-API-Version response header. Shopify serves an inaccessible requested version using its oldest accessible stable version; a successful response alone does not prove the requested version remains supported.

Our recommendation is to include the warning screenshot, last detected unsupported call and deployed version in the support case. Do not assume a persistent warning proves abandonment, or dismiss it as a caching bug without evidence.