Shopify expands monitoring for custom apps

Author

Felix

Published

September 28, 2026

What has Shopify changed?

The Developer Dashboard no longer just shows how a custom app is configured, but also provides greater insight into how it performs during operation.

At the app level, Shopify provides data on API request volume and error rates, among other metrics. For webhooks, you can analyze deliveries, error rates, and performance. Performance data is also available for embedded admin interfaces.

The central logs view brings together various types of events. These include, among others:

GraphQL Admin API Requests
REST Admin API Requests
Webhook Deliveries
Shopify Function Runs
UI Extension Errors
custom app events

Logs can be filtered by shop, event type, status, or HTTP status code, for example. Depending on the event type, additional filters such as webhook topic or GraphQL operation are available.

Shopify retains these logs for 30 days. A single filter window can span a maximum of seven days.

Why is this relevant for Shopify Plus and Enterprise?

The larger a Shopify setup becomes, the less sense it makes to view the store in isolation. An enterprise commerce system can connect Shopify with ERP, PIM, OMS, CRM, fulfillment, data warehouse, loyalty systems, and other services. Custom apps, APIs, webhooks, and Shopify Functions handle some of the communication between these components.

This is precisely where a typical challenge arises: a visible error in the store does not necessarily originate there. If inventory is missing, for example, the cause may lie in the ERP system, middleware, an API call, or a downstream process. The new Shopify logs do not provide visibility into this entire chain. However, they do offer greater transparency into the part that Shopify itself can monitor. API errors, failed webhook deliveries, and function runs can be investigated closer to the platform. For teams operating complex Shopify Plus architectures, the Developer Dashboard thus becomes an additional layer of technical diagnostics.

An example from an enterprise architecture

A merchant automatically transfers new orders from Shopify to their ERP system. A webhook notifies a custom app of a new order, which then processes the data and forwards it to the ERP system. If an order does not arrive there, troubleshooting usually involves tracing the issue across multiple systems.

The new Shopify features make it possible to first check whether the relevant webhook was triggered and delivered. The logs can be filtered by the affected store, time period, and webhook type. API requests and their status can also be investigated.

This makes it easier to narrow down the source of the error: Did Shopify generate the expected event? Was the webhook delivered successfully? Did an API request fail?

What happens after the handoff in your own backend, middleware, or ERP system, however, remains outside Shopify's logs. This boundary is crucial for understanding the scope of the update.

The Moving Primates Perspective

In our view, Shopify is moving some observability capabilities closer to the commerce platform. This makes sense for enterprise projects because, when issues arise, technical teams can more quickly determine whether the cause lies within the processes visible to Shopify or needs to be investigated outside the platform. The link between aggregated metrics and the underlying logs is particularly helpful.

However, this perspective alone is not sufficient for a robust enterprise architecture. End-to-end observability of business-critical processes across system boundaries remains essential. For example, when an order passes through Shopify, a custom app, middleware, and an ERP system, it must be possible to identify where the process was interrupted.

We would therefore not view the new features as a replacement for existing monitoring, but rather as an additional Shopify-native observability layer. The more relevant information is available directly on the platform, the faster teams can narrow down which part of the system landscape needs to be investigated during incidents.

What does this mean for headless commerce?

For headless projects, a distinction must be made between frontend observability and Shopify app monitoring. The new features do not automatically monitor a Hydrogen, Oxygen, or Next.js frontend and therefore do not replace a frontend performance, error tracking, or infrastructure monitoring solution.

They become relevant wherever a headless setup continues to use custom apps, Admin APIs, webhooks, functions, or custom integrations. For example, a headless storefront may be delivered through a separate application, while product data comes from a PIM, inventory is synchronized via an ERP, and orders are processed through additional systems. The new Shopify logs then provide greater transparency into the Shopify side of this architecture.

As a result, headless projects do not have complete end-to-end monitoring. However, the additional visibility can help distinguish more clearly between frontend, Shopify, and backend issues. This is particularly relevant when multiple teams or service providers are responsible for different parts of the commerce stack.

From the error rate directly to the affected request

It is also interesting to see how Shopify correlates metrics and logs. Error rates are displayed alongside the corresponding request or event volume.

This is important because an error rate without context can quickly be misleading. A high error rate across a small number of requests has a different operational significance than the same rate across tens of thousands of requests.

From the relevant charts, developers can switch directly to the filtered log view. This allows them to move from an anomaly at the aggregate level to the underlying events.

For incident analysis, this connection is more relevant than a simple dashboard visualization. A monitoring system should not only show that a problem exists, but also shorten the path to identifying its root cause.

Webhooks are becoming more transparent

Webhooks in particular are critical for commerce integrations. For example, they can trigger orders, product updates, or fulfillment processes between Shopify and other systems.

Shopify provides delivery and failure data for this purpose. Individual webhook entries may include information about the delivery and the respective attempt, among other details.

This is also relevant because persistently failing webhooks can have operational consequences. Shopify retries failed deliveries. If the errors persist, the corresponding subscription may eventually be removed.

For business-critical processes, action should therefore not be delayed until a merchant notices a missing record. Monitoring and alerting should make errors visible as early as possible.

What Shopify doesn't solve with this

The new monitoring layer has a clear limitation: Shopify can only display events that Shopify itself can see or that an app explicitly sends to Shopify via App Events.

For example, a request sent directly from the browser to your own backend does not automatically appear in these logs. The same applies to internal processes in middleware, ERP, PIM, or other external services.

There are also limitations for long-term analyses. Shopify currently retains logs for 30 days, and any single queried period may span no more than seven days.

For enterprise setups, external solutions for logging, alerting, application performance monitoring, and distributed tracing therefore remain relevant, depending on the architecture. It is particularly important to link the individual systems using shared IDs or events. Only then can a business process such as an order be fully traced across multiple technical components.

What should enterprise teams review now?

For existing Shopify Plus setups, we would not initially try to monitor every available signal. It makes more sense to start with the business-critical processes.

1. Identify critical custom apps
Which apps affect checkout, orders, inventory, pricing, fulfillment, or product data?

2. Document critical webhooks
Which processes no longer function correctly if a specific webhook fails?

3. Check API error rates
Are there already any notable errors or recurring issues with certain operations?

4. Include Shopify Functions
Business-critical Functions should also be included in technical monitoring.

5. Define responsibilities
Who responds to an error: the internal commerce team, an agency, or an external integration partner?

6. Connect Shopify and external monitoring
For relevant processes, it should be clear where Shopify’s visibility ends and which systems take over from there.

What does shared access mean for agencies?

Shopify explicitly states that agencies and developers who build custom apps for merchants can access the same performance data. This is organizationally relevant for Shopify Plus projects under ongoing management.

When a merchant reports an issue, the technical analysis does not have to begin solely with screenshots or exported information. The merchant and development partner can look at the same Shopify-native data source.

This can be particularly helpful for incidents where it is initially unclear which system is responsible. At the same time, access rights should continue to be granted deliberately. Monitoring data may contain technical details about integrations and business processes.

This shared view therefore improves not only debugging, but potentially also collaboration between the commerce team, the agency, and other technology partners.

Summary

Shopify is expanding the Developer Dashboard to provide significantly greater transparency into the ongoing operation of custom apps. API requests, error rates, webhook deliveries, function runs, UI extension errors, and custom app events can now be investigated more centrally, with some issues traceable directly from an anomalous metric to the underlying logs. For Shopify Plus and Enterprise projects, this primarily improves diagnostics on the Shopify side of complex integrations.

From our perspective, however, this is not a complete observability solution for an enterprise commerce architecture. ERP, PIM, middleware, headless frontends, and other external services remain outside Shopify’s scope of visibility unless relevant events are explicitly reported back. The new features are therefore best viewed as an additional Shopify-native observability layer. When properly integrated, they can help narrow down fault domains more quickly and reduce the time between an incident and identifying its technical root cause.

FAQ

What has Shopify changed about monitoring custom apps?

Shopify has expanded the Developer Dashboard with additional performance and diagnostic information. Developers can examine API request volume and error rates, webhook delivery health, and performance data for embedded admin pages, among other things. A centralized logs view also brings together API requests, webhook deliveries, function runs, UI extension errors, and custom app events. Entries can be filtered by criteria such as shop, type, and status. This makes it easier to move quickly from a general anomaly to specific requests or events when troubleshooting technical issues.

Why is the new monitoring important for Shopify Plus and Enterprise?

With Shopify Plus and Enterprise, Shopify is often just one part of a larger commerce architecture. ERP, PIM, OMS, CRM, fulfillment, middleware, and custom services communicate with one another via APIs, webhooks, Functions, and custom apps. Therefore, when a process fails, the first step is to determine which system caused the error.

The new monitoring features improve precisely this type of analysis on the Shopify side. Teams can check whether webhooks were delivered, API requests generated errors, or Functions are behaving unusually, and then examine the associated logs. This does not automatically make the entire system landscape observable. However, it does provide a more detailed Shopify-native view. Combined with external monitoring, this can help narrow down incidents more quickly and identify the technical root cause of a problem more systematically across multiple systems involved.

Does the new Developer Dashboard replace external observability?

No. Shopify primarily displays events that are visible within the platform or reported by an app via App Events. Processes within a custom backend, middleware, ERP, or PIM system are not automatically captured. For complex enterprise architectures, external logging, alerting, APM, and distributed tracing solutions may therefore still be necessary. The Developer Dashboard complements these systems by providing a more detailed, Shopify-native view.

Are the new logs also relevant for headless shops?

Yes, but not as a replacement for monitoring the headless frontend. A Hydrogen, Oxygen, or Next.js frontend still requires its own performance and error monitoring. Shopify logs are relevant for the underlying integrations. If a headless setup uses custom apps, Admin APIs, webhooks, or Shopify Functions, these processes can be investigated in the Developer Dashboard. This makes it easier to distinguish between issues in the storefront, on Shopify’s side, and in external systems.

How long does Shopify retain logs?

Shopify currently retains logs in the Developer Dashboard for 30 days. A single selected time window can span no more than seven days. Therefore, investigations covering longer periods require reviewing multiple consecutive time windows. Companies that need to retain logs for longer periods or require historical data for compliance, incident reviews, or long-term performance analysis should therefore assess whether an additional external logging or observability solution is needed.

Can agencies view the monitoring data of custom apps?

Shopify states that agencies and developers who build custom apps for merchants can access the same performance data. For ongoing enterprise support, this can simplify collaboration because merchants and development partners can refer to the same Shopify-native information during an incident. This does not replace clearly defined responsibilities, but it can speed up the initial diagnosis and help determine whether an issue requires further investigation on Shopify’s side or in an external system.