Shopify erweitert das Monitoring für Custom Apps

Author

Felix

Veröffentlicht

28. September 2026

Was hat Shopify geändert?

Das Developer Dashboard zeigt nicht mehr nur, wie eine Custom App eingerichtet ist, sondern stärker auch, wie sie sich im laufenden Betrieb verhält.

Auf App-Ebene stellt Shopify unter anderem Daten zu API Request Volume und Error Rates bereit. Bei Webhooks lassen sich Zustellungen, Fehlerraten und Performance untersuchen. Für eingebettete Admin-Oberflächen werden ebenfalls Performance-Daten bereitgestellt.

Die zentrale Logs-Ansicht führt verschiedene Ereignistypen zusammen. Dazu gehören unter anderem:

GraphQL Admin API Requests
REST Admin API Requests
Webhook Deliveries
Shopify Function Runs
UI Extension Errors
eigene App Events

Logs können beispielsweise nach Shop, Event-Typ, Status oder HTTP-Statuscode gefiltert werden. Je nach Event-Typ kommen weitere Filter wie Webhook Topic oder GraphQL Operation hinzu.

Shopify behält diese Logs für 30 Tage vor. Ein einzelnes Filterfenster kann maximal sieben Tage umfassen.

Warum ist das für Shopify Plus und Enterprise relevant?

Je größer ein Shopify-Setup wird, desto weniger sinnvoll ist es, den Shop isoliert zu betrachten. Ein Enterprise-Commerce-System kann Shopify mit ERP, PIM, OMS, CRM, Fulfillment, Data Warehouse, Loyalty-Systemen und weiteren Services verbinden. Custom Apps, APIs, Webhooks und Shopify Functions übernehmen dabei einen Teil der Kommunikation zwischen diesen Komponenten.

Genau hier entsteht eine typische Herausforderung: Ein sichtbarer Fehler im Shop muss nicht dort entstanden sein. Fehlt beispielsweise ein Bestand, kann die Ursache im ERP, in einer Middleware, beim API-Aufruf oder in einem nachgelagerten Prozess liegen. Die neuen Shopify-Logs lösen diese gesamte Kette nicht auf. Sie schaffen aber mehr Transparenz für den Teil, den Shopify selbst beobachten kann. API-Fehler, fehlgeschlagene Webhook-Zustellungen oder Function Runs können näher an der Plattform untersucht werden. Für Teams, die komplexe Shopify-Plus-Architekturen betreiben, wird das Developer Dashboard damit zu einer zusätzlichen Ebene der technischen Diagnose.

Ein Beispiel aus einer Enterprise-Architektur

Ein Händler überträgt neue Bestellungen automatisiert von Shopify an sein ERP. Ein Webhook informiert eine Custom App über eine neue Order, die anschließend Daten verarbeitet und an das ERP weitergibt. Kommt eine Bestellung dort nicht an, beginnt die Fehlersuche normalerweise über mehrere Systeme hinweg.

Mit den neuen Shopify-Funktionen kann zunächst geprüft werden, ob der entsprechende Webhook ausgelöst und zugestellt wurde. Die Logs lassen sich auf den betroffenen Shop, Zeitraum und Webhook-Typ eingrenzen. Auch API Requests und deren Status können untersucht werden.

Damit lässt sich die Fehlerdomäne schneller eingrenzen: Hat Shopify das erwartete Ereignis erzeugt? Wurde der Webhook erfolgreich zugestellt? Ist ein API Request fehlgeschlagen?

Was nach der Übergabe im eigenen Backend, in einer Middleware oder im ERP passiert, bleibt dagegen außerhalb der Shopify-Logs. Genau diese Grenze ist für die Einordnung des Updates wichtig.

Die Moving-Primates-Perspektive

Aus unserer Sicht verschiebt Shopify einen Teil der Observability näher an die Commerce-Plattform. Das ist für Enterprise-Projekte sinnvoll, weil technische Teams bei Problemen schneller unterscheiden können, ob die Ursache innerhalb der von Shopify sichtbaren Prozesse liegt oder außerhalb der Plattform gesucht werden muss. Besonders hilfreich ist die Verbindung von aggregierten Metriken mit den zugrunde liegenden Logs.

Für eine belastbare Enterprise-Architektur reicht diese Sicht allein jedoch nicht aus. Entscheidend bleibt eine durchgängige Beobachtbarkeit der geschäftskritischen Prozesse über Systemgrenzen hinweg. Wenn eine Bestellung beispielsweise Shopify, eine Custom App, Middleware und ERP durchläuft, muss nachvollziehbar sein, an welcher Stelle ein Prozess unterbrochen wurde.

Wir würden die neuen Funktionen deshalb nicht als Ersatz für bestehendes Monitoring betrachten, sondern als zusätzliche Shopify-native Observability-Schicht. Je mehr relevante Informationen direkt an der Plattform verfügbar sind, desto schneller kann bei Incidents eingegrenzt werden, welcher Teil der Systemlandschaft untersucht werden muss.

Was bedeutet das für Headless Commerce?

Für Headless-Projekte muss zwischen Frontend-Observability und Shopify-App-Monitoring unterschieden werden. Die neuen Funktionen überwachen nicht automatisch ein Hydrogen-, Oxygen- oder Next.js-Frontend und ersetzen deshalb keine Frontend-Performance-, Error-Tracking- oder Infrastructure-Monitoring-Lösung.

Relevant werden sie dort, wo ein Headless-Setup weiterhin Custom Apps, Admin APIs, Webhooks, Functions oder individuelle Integrationen verwendet. Ein Headless Storefront kann beispielsweise über eine separate Anwendung ausgeliefert werden, während Produktdaten aus einem PIM kommen, Bestände über ein ERP synchronisiert und Bestellungen über weitere Systeme verarbeitet werden. Die neuen Shopify-Logs schaffen dann mehr Transparenz auf der Shopify-Seite dieser Architektur.

Für Headless-Projekte entsteht deshalb kein vollständiges End-to-End-Monitoring. Die zusätzliche Sicht kann aber helfen, Frontend-, Shopify- und Backend-Probleme sauberer voneinander zu trennen. Das ist insbesondere dann relevant, wenn mehrere Teams oder Dienstleister unterschiedliche Teile des Commerce-Stacks verantworten.

Von der Fehlerrate direkt zum betroffenen Request

Interessant ist auch, wie Shopify Metriken und Logs miteinander verbindet. Fehlerraten werden gemeinsam mit dem jeweiligen Request- beziehungsweise Event-Volumen dargestellt.

Das ist wichtig, weil eine Fehlerrate ohne Kontext schnell irreführend sein kann. Eine hohe Fehlerquote bei wenigen Requests hat eine andere operative Bedeutung als dieselbe Quote bei zehntausenden Requests.

Aus den entsprechenden Charts kann direkt in die gefilterte Log-Ansicht gewechselt werden. Entwickler gelangen dadurch von einer Auffälligkeit auf aggregierter Ebene zu den Ereignissen, die dahinterstehen.

Für die Incident-Analyse ist diese Verbindung relevanter als eine reine Dashboard-Visualisierung. Ein Monitoring-System sollte nicht nur zeigen, dass ein Problem existiert, sondern den Weg zur eigentlichen Ursache verkürzen.

Webhooks werden transparenter

Gerade Webhooks sind bei Commerce-Integrationen kritisch. Sie können beispielsweise Bestellungen, Produkte oder Fulfillment-Prozesse zwischen Shopify und anderen Systemen anstoßen.

Shopify stellt dafür Delivery- und Failure-Daten bereit. Einzelne Webhook-Einträge können unter anderem Informationen zur Zustellung und zum jeweiligen Versuch enthalten.

Das ist auch deshalb relevant, weil dauerhaft fehlschlagende Webhooks operative Folgen haben können. Shopify versucht fehlgeschlagene Zustellungen erneut. Bleiben Fehler bestehen, kann die entsprechende Subscription schließlich entfernt werden.

Bei geschäftskritischen Prozessen sollte deshalb nicht erst reagiert werden, wenn ein Merchant einen fehlenden Datensatz bemerkt. Monitoring und Alerting sollten Fehler möglichst vorher sichtbar machen.

Was Shopify damit nicht löst

Die neue Monitoring-Ebene hat eine klare Grenze: Shopify kann nur Ereignisse darstellen, die Shopify selbst sieht oder die eine App explizit über App Events an Shopify sendet.

Ein Request vom Browser direkt an ein eigenes Backend taucht beispielsweise nicht automatisch in diesen Logs auf. Gleiches gilt für interne Prozesse in Middleware, ERP, PIM oder anderen externen Services.

Auch für langfristige Analysen bestehen Grenzen. Shopify hält die Logs aktuell 30 Tage vor, und ein einzelner abgefragter Zeitraum darf maximal sieben Tage umfassen.

Für Enterprise-Setups bleiben deshalb je nach Architektur externe Lösungen für Logging, Alerting, Application Performance Monitoring und Distributed Tracing relevant. Besonders wichtig ist dabei die Verbindung der einzelnen Systeme über gemeinsame IDs oder Events. Erst dadurch lässt sich ein Geschäftsprozess wie eine Bestellung über mehrere technische Komponenten hinweg vollständig nachvollziehen.

Was sollten Enterprise-Teams jetzt prüfen?

Für bestehende Shopify-Plus-Setups würden wir zunächst nicht versuchen, jedes verfügbare Signal zu überwachen. Sinnvoller ist es, von den geschäftskritischen Prozessen auszugehen.

1. Kritische Custom Apps identifizieren
Welche Apps beeinflussen Checkout, Orders, Inventory, Pricing, Fulfillment oder Produktdaten?

2. Kritische Webhooks dokumentieren
Welche Prozesse funktionieren nicht mehr korrekt, wenn ein bestimmter Webhook ausfällt?

3. API-Fehlerraten prüfen
Gibt es bereits auffällige Fehler oder wiederkehrende Probleme bei bestimmten Operations?

4. Shopify Functions berücksichtigen
Geschäftskritische Functions sollten ebenfalls Teil der technischen Überwachung sein.

5. Verantwortlichkeiten definieren
Wer reagiert auf einen Fehler: internes Commerce-Team, Agentur oder externer Integrationspartner?

6. Shopify- und externes Monitoring verbinden
Für relevante Prozesse sollte nachvollziehbar sein, wo die Shopify-Sicht endet und welche Systeme anschließend übernehmen.

Was bedeutet der gemeinsame Zugriff für Agenturen?

Shopify nennt ausdrücklich, dass Agenturen und Entwickler, die Custom Apps für Händler erstellen, dieselben Performance-Daten sehen können. Für laufend betreute Shopify-Plus-Projekte ist das organisatorisch relevant.

Wenn ein Händler einen Fehler meldet, muss die technische Analyse dadurch nicht ausschließlich mit Screenshots oder exportierten Informationen beginnen. Merchant und Entwicklungspartner können auf dieselbe Shopify-native Datengrundlage schauen.

Das kann insbesondere bei Incidents helfen, bei denen zunächst unklar ist, welches System verantwortlich ist. Gleichzeitig sollten Zugriffsrechte weiterhin bewusst vergeben werden. Monitoring-Daten können technische Details über Integrationen und Geschäftsprozesse enthalten.

Die gemeinsame Sicht verbessert damit nicht nur Debugging, sondern potenziell auch die Zusammenarbeit zwischen Commerce-Team, Agentur und weiteren Technologiepartnern.

Zusammenfassung

Shopify erweitert das Developer Dashboard um deutlich mehr Transparenz für den laufenden Betrieb von Custom Apps. API Requests, Fehlerraten, Webhook-Zustellungen, Function Runs, UI-Extension-Fehler und eigene App Events lassen sich zentraler untersuchen und teilweise direkt von einer auffälligen Metrik bis zu den zugrunde liegenden Logs verfolgen. Für Shopify-Plus- und Enterprise-Projekte verbessert das vor allem die Diagnose auf der Shopify-Seite komplexer Integrationen.

Aus unserer Sicht ist das jedoch keine vollständige Observability-Lösung für eine Enterprise-Commerce-Architektur. ERP, PIM, Middleware, Headless Frontend und weitere externe Services bleiben außerhalb der Shopify-Sicht, sofern relevante Ereignisse nicht gezielt zurückgemeldet werden. Die neuen Funktionen sind deshalb am stärksten als zusätzliche Shopify-native Observability-Schicht. Richtig eingebunden können sie helfen, Fehlerdomänen schneller einzugrenzen und die Zeit zwischen einer Störung und ihrer technischen Ursache zu verkürzen.

FAQ

Was hat Shopify beim Monitoring von Custom Apps geändert?

Shopify hat das Developer Dashboard um zusätzliche Performance- und Diagnoseinformationen erweitert. Entwickler können unter anderem API Request Volume und Error Rates, Webhook Delivery Health sowie Performance-Daten eingebetteter Admin-Seiten untersuchen. Eine zentrale Logs-Ansicht verbindet außerdem API Requests, Webhook Deliveries, Function Runs, UI-Extension-Fehler und eigene App Events. Die Einträge können beispielsweise nach Shop, Typ und Status gefiltert werden. Dadurch lässt sich bei technischen Problemen schneller von einer allgemeinen Auffälligkeit zu konkreten Requests oder Events wechseln.

Warum ist das neue Monitoring für Shopify Plus und Enterprise wichtig?

Bei Shopify Plus und Enterprise ist Shopify häufig nur ein Teil einer größeren Commerce-Architektur. ERP, PIM, OMS, CRM, Fulfillment, Middleware und individuelle Services kommunizieren über APIs, Webhooks, Functions und Custom Apps miteinander. Wenn ein Prozess ausfällt, muss deshalb zunächst festgestellt werden, in welchem System der Fehler entstanden ist.

Die neuen Monitoring-Funktionen verbessern genau diese Analyse auf der Shopify-Seite. Teams können prüfen, ob Webhooks zugestellt wurden, API Requests Fehler erzeugen oder Functions auffällig sind und anschließend die dazugehörigen Logs untersuchen. Damit wird nicht automatisch die gesamte Systemlandschaft beobachtbar. Die Shopify-native Sicht wird jedoch detaillierter. In Kombination mit externem Monitoring kann das helfen, Incidents schneller einzugrenzen und die technische Ursache eines Problems über mehrere beteiligte Systeme hinweg systematischer zu finden.

Ersetzt das neue Developer Dashboard externe Observability?

Nein. Shopify zeigt vor allem Ereignisse, die innerhalb der Plattform sichtbar sind oder von einer App über App Events gemeldet werden. Prozesse innerhalb eines eigenen Backends, einer Middleware, eines ERP oder eines PIM werden dadurch nicht automatisch erfasst. Für komplexe Enterprise-Architekturen können deshalb weiterhin externe Logging-, Alerting-, APM- und Distributed-Tracing-Lösungen notwendig sein. Das Developer Dashboard ergänzt diese Systeme um eine detailliertere Shopify-native Sicht.

Sind die neuen Logs auch für Headless Shops relevant?

Ja, allerdings nicht als Ersatz für das Monitoring des Headless Frontends. Ein Hydrogen-, Oxygen- oder Next.js-Frontend benötigt weiterhin eine eigene Überwachung für Performance und Fehler. Relevant sind die Shopify-Logs für die dahinterliegenden Integrationen. Verwendet ein Headless-Setup Custom Apps, Admin APIs, Webhooks oder Shopify Functions, können diese Prozesse im Developer Dashboard untersucht werden. Dadurch lassen sich Probleme im Storefront, auf Shopify-Seite und in externen Systemen besser voneinander abgrenzen.

Wie lange speichert Shopify die Logs?

Shopify hält die Logs im Developer Dashboard aktuell für 30 Tage vor. Ein einzelnes ausgewähltes Zeitfenster kann maximal sieben Tage umfassen. Für längere Untersuchungszeiträume müssen daher mehrere Zeitfenster nacheinander betrachtet werden. Unternehmen, die Logs über längere Zeiträume aufbewahren müssen oder historische Daten für Compliance, Incident Reviews oder langfristige Performance-Analysen benötigen, sollten deshalb prüfen, ob zusätzlich eine externe Logging- beziehungsweise Observability-Lösung erforderlich ist.

Können Agenturen die Monitoring-Daten von Custom Apps sehen?

Shopify gibt an, dass Agenturen und Entwickler, die Custom Apps für Händler erstellen, dieselben Performance-Daten einsehen können. Für laufende Enterprise-Betreuung kann das die Zusammenarbeit vereinfachen, weil Händler und Entwicklungspartner bei einem Incident auf dieselbe Shopify-native Informationsbasis zugreifen können. Das ersetzt keine klaren Verantwortlichkeiten, kann aber die erste Diagnose beschleunigen und helfen festzustellen, ob ein Problem auf Shopify-Seite oder in einem externen System weiter untersucht werden muss.