Data6 min Lesezeit

Shopware 6 ohne Observability: Warum die meisten Shops Blindflug machen

27.5.2026
Shopware 6 ohne Observability: Warum die meisten Shops Blindflug machen
Euer Shop läuft - aber wisst ihr verlässlich, ob der Checkout heute Geld kostet? Drei Ebenen, ein pragmatischer Stack und warum „es läuft doch" die teuerste Antwort ist, die ihr als Shop-Betreiber geben könnt.

Euer Shopware-Shop läuft. Bestellungen kommen rein, der Umsatz stimmt, niemand schreit. Aber wenn euch heute jemand fragt: „Funktioniert euer Checkout gerade so schnell wie letzte Woche?" - könnt ihr das verlässlich beantworten? In den meisten Shops, die wir uns ansehen, ist die ehrliche Antwort: nein. Und genau das ist das Problem.

Wenn ein Kunde anruft und sagt „die Seite lädt ewig", öffnet jemand den Browser, klickt selbst drauf und sagt „bei mir geht's". Das ist kein Monitoring. Das ist Raten - und es kostet euch Geld, ohne dass ihr es merkt.

Das „Es läuft doch"-Syndrom

Wie tief dieses Problem sitzt, sieht man erst, wenn man hinschaut. Stellvertretendes Beispiel aus einem unserer Projekte: ein Shopware-6-Shop mit knapp 30.000 Produkten, einem selbstgebauten B2B-Modul und einer Anbindung an ein externes Warenwirtschaftssystem. Der Kunde war zufrieden - der Shop lief. Dachten alle Beteiligten.

Bis wir beim Einrichten eines vernünftigen Monitorings drei Dinge innerhalb der ersten 24 Stunden fanden. Vermutlich existieren ähnliche Probleme in eurem Shop genauso - nur kennt sie aktuell niemand:

  1. Der Product-Export in die Wawi brach jede Nacht um 02:17 ab. Der Cronjob lief in einen Timeout, rollte still zurück und versuchte es beim nächsten Durchlauf erneut. Kein Log-Eintrag oberhalb von DEBUG-Level. Seit sechs Wochen - während Produktdaten leise veralteten.

  2. Die Checkout-Conversion war an Wochentagen zwischen 10:00 und 10:30 um 40 % niedriger. Ursache: Ein Redis-Snapshot, der den Session-Handler für exakt diese halbe Stunde in die Knie zwang. Hochgerechnet auf einen Monat: ein fünfstelliger Umsatzverlust, den niemand auf dem Schirm hatte.

  3. Der Elasticsearch-Index war seit dem letzten Shopware-Minor-Update verwaist. Die Suche funktionierte trotzdem - sie fiel lautlos auf MySQL FULLTEXT zurück. Niemand hatte den Performance-Unterschied bemerkt, weil „die Suche ja Ergebnisse liefert". Die Frage ist nur: Wie viele Kunden haben die schlechteren Treffer einfach weggeklickt?

Drei kritische Probleme. Null Alarme. Sechs Monate Betrieb. Und das in einem Shop, dessen Betreiber dachten, alles sei unter Kontrolle.

Was „Monitoring" in den meisten Shops wirklich heißt

Wenn wir in Gesprächen fragen, was an Monitoring läuft, klingt die Antwort fast immer wie eine dieser drei. Schaut ehrlich, welche zu eurem Shop passt:

  • „Wir haben das Shopware-Health-Check-Plugin."

  • „Unser Hoster macht das."

  • „Wir kriegen eine Mail, wenn der Shop down ist."

Wenn ihr euch hier wiedererkennt: Das ist ungefähr so, als würdet ihr euer Auto warten, indem ihr nur guckt, ob die Motorlampe leuchtet. Der Shopware-Health-Check sagt euch, ob PHP läuft und die Datenbank antwortet. Er sagt euch nicht, ob euer Checkout funktioniert, ob Drittanbieter-APIs antworten oder ob eure Cache-Hit-Rate gerade von 92 % auf 34 % gefallen ist.

Ein typisches Shop-Setup, in das auch euer System wahrscheinlich grob passt: Shopware 6 → MySQL → Redis → Elasticsearch - und keine dieser Komponenten hat richtiges Monitoring. Jede kann teilweise ausfallen, ohne dass euer Shop komplett „down" geht. Genau das macht es so gefährlich: Euer Shop stirbt nicht dramatisch - er degradiert. Und degradierte Shops kosten Umsatz, ohne dass jemand es mitbekommt.

Die drei Ebenen, die ihr als Shop-Betreiber braucht

Damit aus „der Shop fühlt sich okay an" eine belastbare Aussage wird, braucht ihr Transparenz auf drei Ebenen. Keine davon ist Selbstzweck - jede beantwortet eine konkrete Frage, die euch sonst Geld kostet.

Ebene 1: Infrastruktur. CPU, RAM, Disk-I/O, Netzwerk-Durchsatz. Das macht euer Hoster meistens - aber nur auf Server-Ebene, nicht pro Dienst. Wenn Redis einen Memory-Spike hat, während MySQL gleichzeitig schläft, seht ihr auf der Hoster-Übersicht nur „Server OK". Die Frage, die diese Ebene beantworten muss: Hat eure Plattform überhaupt die Ressourcen, um die heutige Last zu tragen?

Ebene 2: Applikation. Transaction Traces für euren Checkout, Cache-Hit-Rates pro Storefront-Route, Queue-Durchsatz, Scheduled Tasks. Shopwares Scheduled-Task-System ist ein schwarzes Loch: Tasks können mit Status queued festhängen, ohne dass irgendwas loggt - und ihr merkt es erst, wenn Bestellungen nicht mehr ans ERP gehen. Die Frage hier: Macht euer Shopware intern noch das, was es soll - oder hakt es leise an Stellen, die niemand sieht?

Ebene 3: Business. Checkout-Funnel, API-Latenzen zu Drittsystemen (Wawi, Payment, Versand), Produktdaten-Konsistenz. Wenn die DHL-API plötzlich 4 statt 0,2 Sekunden braucht, wollt ihr das wissen, bevor eure Kunden die Versandkosten nicht berechnet kriegen - nicht erst, wenn die Support-Tickets reinrasseln. Die Frage, die euch direkt Geld bringt: Verdient euer Shop heute genauso zuverlässig wie gestern?

Ein pragmatischer Stack, mit dem ihr anfangen könnt

Ihr braucht keine sechsstellige Tooling-Investition, um aus dem Blindflug rauszukommen. Mit drei Komponenten deckt ihr die wichtigsten Lücken ab - und könnt sie schrittweise aufbauen, statt alles auf einmal:

  • Prometheus + Grafana für Metriken. Der Shopware-eigene Metrik-Endpunkt liefert euch einen guten Einstieg, ergänzt mit eigenen Exportern für Queue-Tiefe und Checkout-Funnel. Dashboards, die ihr selbst lesen könnt, sind mehr wert als ein SaaS-Tool, dessen Login niemand im Team kennt.

  • OpenTelemetry für Traces. In Symfony/Shopware per Bundle relativ schmerzfrei einzubinden. Damit seht ihr, an welcher Stelle im Request-Lifecycle die Zeit verloren geht - und müsst nicht mehr raten, ob „der Checkout lahm" am Plugin, am Payment-Provider oder an der Datenbank liegt.

  • Uptime Kuma oder Blackbox Exporter für synthetische Checks. „Kann ich ein Produkt in den Warenkorb legen?" als HTTP-Sequenz, alle 60 Sekunden. So merkt ihr es als Erste, wenn euer Checkout bricht - nicht eure Kunden.

Der wichtigste Schritt ist nicht das Tool. Es ist die Entscheidung, Observability als Teil eures Projekts zu behandeln - nicht als optionales Add-on, das „irgendwann nach dem Go-Live" kommt. In der Praxis kommt es nämlich nie, solange niemand bei euch dafür Budget reserviert.

Fazit

Wenn euer Shop im Monat 50.000 € Umsatz macht und ihr kein Monitoring habt, das euch sagt, ob der Checkout funktioniert, dann verliert ihr Geld. Jeden Tag. Ihr wisst es nur nicht.

Fangt mit den drei Business-Metriken an, die euch direkt Geld kosten - Checkout-Rate, Payment-API-Response, Search-Fallback. Baut dafür Alerts. Alles Weitere kommt danach. Was sich an Conversion oder Umsatz konkret bewegt, lässt sich seriös erst nach den ersten Wochen Monitoring sagen - Kataloggröße, Traffic und Plugin-Setup sind bei jedem Shop anders. Genau deshalb messen wir, statt zu versprechen.

Wenn euer Shopware-Shop läuft, aber niemand verlässlich sagen kann, ob euer Checkout heute schneller oder langsamer ist als letzte Woche - lasst uns 30 Minuten über euren konkreten Shop reden. Wir schauen, welche drei Metriken bei euch zuerst Geld bringen würden und welche Tools dafür wirklich nötig sind. Kein Pitch-Deck.

Gespräch anfragen

Teilen Sie diesen Artikel: