Der Shop antwortet mit HTTP 200, aber der Button „In den Warenkorb“ tut nichts – solche Ausfälle sieht eine serverseitige Überwachung nicht. Monitorio erfasst JavaScript-Fehler im Browser deiner Besucher und fasst gleichartige Fehler zu einer Gruppe zusammen: Du siehst etwa „dieser eine Fehler, 400-mal“ statt 400 einzelner Meldungen.
Die Daten kommen aus dem Browser deiner Besucher: Ein kleines Skript in der Storefront meldet Laufzeitfehler und unbehandelte Promise-Rejections an Monitorio. Dort landen gleichartige Fehler in einer gemeinsamen Gruppe. Solange das Skript fehlt, bleibt die Fehlerliste leer, ohne dass etwas kaputt wäre.
Zusammengefasst wird über Fehlertyp, Meldung und die obersten Stack-Zeilen. Zeilennummern, Datei-Hashes und Query-Strings fallen vorher heraus – deshalb bleibt ein Fehler nach einem Deployment dieselbe Gruppe, obwohl sich Dateiname und Zeile geändert haben.
Fehler, deren Stacktrace vollständig aus einer Browser-Erweiterung stammt, fallen von vornherein weg. Das ist fremder Code, den du gar nicht auslieferst.
Skripte fremder Domains ohne CORS-Header liefern nur „Script error.“ ohne Stacktrace. Diese Meldungen fallen zu genau einer Sammelgruppe zusammen: Ihr Inhalt sagt nichts, ihre Häufigkeit schon.
Übernimmt das Plugin den Einbau, kommt zu jedem Fehler der Seitenbereich mit: Storefront, Checkout oder Konto. Danach filterst du die Liste – das lohnt vor allem für den Checkout, denn Fehler dort kosten unmittelbar Umsatz, gehen in der Gesamtliste aber zwischen harmlosen Meldungen unter.
Angenommen wird nur, was von einer deiner Shop-Domains kommt. Bei Shopware-Projekten mit hinterlegten API-Zugangsdaten holt Monitorio die Domains aller Sales Channels stündlich selbst aus Shopware. Staging-Domains oder CDN-Hosts ergänzt du von Hand.
Fehler mit gültigem Schlüssel von einer unbekannten Adresse landen in einer Warteliste statt im Müll. Ist es deine Domain, holst du sie mit „Übernehmen“ rückwirkend in die Liste, sonst wählst du „Verwerfen“. Wartende Fehler lösen keinen Alarm aus.
Die Alarme teilen sich die Arbeit: „Neuer JavaScript-Fehler“ deckt das Erstauftreten ab, „JavaScript-Fehler ist zurück“ die Rückfälle und „JavaScript-Fehlerrate auffällig“ die Menge. Eine gemeldete Fehlergruppe wird entwarnt, wenn der Fehler aufhört – nicht, wenn er alt wird. Die Entwarnung kommt als eigene Meldung und nennt den ursprünglichen Fehler samt Meldedatum.
Meldet, wenn in der Storefront eine Fehlerart auftaucht, die es vorher nicht gab – der übliche Fall nach einem Deploy, einem Theme-Update oder einem neu eingebundenen Drittanbieter-Skript. Wiederkehrende alte Fehler lösen ihn nicht aus.
Voreinstellung: ab 3 Vorkommen, gilt 24 Stunden als neu, Entwarnung nach 24 Stunden Stille bei mindestens 100 Seitenaufrufen
Meldet, wenn je Seitenaufruf deutlich mehr Fehler auftreten als sonst – auch ohne neue Fehlerart, etwa wenn ein Deploy einen längst bekannten Fehler plötzlich zehnmal so oft auslöst.
Voreinstellung: 3-fache übliche Rate, letzte Stunde gegen 7 Tage, mindestens 200 Seitenaufrufe im Fenster, Entwarnung nach 2 ruhigen Fenstern
Meldet, wenn eine schon entwarnte Fehlergruppe wieder auftritt. Gezählt werden nur die Vorkommen seit der Entwarnung, mit höherer Schwelle als beim Erstauftreten – so flattert ein instabiler Fehler nicht ewig zwischen „neu“ und „entwarnt“.
Voreinstellung: 5 Vorkommen seit der Entwarnung
Ohne Skript bleibt die Liste genauso leer wie bei einem fehlerfreien Shop. Die Zähler in der Einrichtungsansicht trennen beides: Steigen die Seitenaufrufe, aber nicht die Ereignisse, läuft das Skript und dein Shop ist sauber. Bleibt beides bei null, ist das Skript nicht angekommen.
Bei 1 meldet dir jede kaputte Browser-Erweiterung eines einzelnen Besuchers etwas. Ab 3, der Voreinstellung, bleiben Einzelausreißer stumm – was übrig bleibt, betrifft mehrere Besucher.
Entwarnt wird erst, wenn eine Gruppe seit der eingestellten Zeit still war und es dabei genug Seitenaufrufe gab – voreingestellt 24 Stunden und 100 Aufrufe. Fehlt der Beleg, bleibt die Gruppe offen, und die Detailansicht schreibt „wartet auf Traffic-Beleg“ dazu.
Einen Fehler, den du kennst und nicht beheben kannst – etwa aus einem Drittanbieter-Skript –, stellst du in der Detailansicht still: Die Gruppe zählt weiter, löst aber keinen Alarm mehr aus. Ganze Klassen wie ein Consent-Tool, alles unter /admin oder einen Bot nimmst du unter „Ausnahmen“ gar nicht erst an.
Jede Ausnahme-Regel zeigt, wie viel sie verworfen hat und wann zuletzt. Schau da hin, bevor du dich über Ruhe freust – in der Liste sehen beide Fälle gleich aus. Schalte eine Regel lieber ab, statt sie zu löschen, dann bleibt diese Zahl erhalten.
Der häufigste Auslöser ist der letzte Deploy: Vergleiche „zuerst gesehen“ mit deinem Deployment-Zeitpunkt. Liefert das Plugin den Theme-Build mit, steht er direkt in der Gruppe („Erstmals in Build“) – passt er zu einem Release, hast du den Verursacher und einen Rollback-Pfad.
Steht in der Gruppe nur eine einzelne Produktseite, ist es meist ein Datenproblem. Verteilt sich der Fehler über den ganzen Shop, kommt er aus dem Theme oder einem Plugin. Die Geräteklasse zeigt, ob er nur auf Mobile auftritt.
Der typische Storefront-Fehler ist Folge, nicht Ursache: Liefert etwa POST /checkout/line-item/add den Status 500, stolpert das JavaScript danach über undefined. Der Stacktrace zeigt die Stolperstelle, die fehlgeschlagenen Aufrufe davor zeigen die Ursache.
Damit Fehler ankommen, muss ein kleines Skript in der Storefront laufen. Dafür gibt es zwei gleichwertige Wege: Unser Plugin emz/monitorio kann den Einbau übernehmen, wenn es dafür konfiguriert ist – dann kommen Sales-Channel, Seitenbereich und Theme-Build gleich mit, und du musst am Template nichts anfassen. Ebenso kannst du die beiden Zeilen selbst in den <head> jeder Seite setzen; die Einrichtungsansicht in Monitorio zeigt sie fertig zum Kopieren.
emz/monitorio auf PackagistZu jedem Fehler erfasst das Skript Fehlertyp, Meldung, Stack, Skript-Datei mit Zeilenangabe, die Seiten-URL ohne Query-String und den Viewport, dazu – falls es einen gab – den zuletzt fehlgeschlagenen Netzwerk-Aufruf mit Methode, Adresse ohne Query-String und Status. Den User-Agent liest Monitorio aus der Anfrage. Beim Einbau über das Plugin kommen Sales-Channel, Seitenbereich und Theme-Build hinzu; außerdem zählt das Skript Seitenaufrufe. Es sendet ohne Cookies. Mit den Fehlerdaten speichert Monitorio keine IP-Adresse; sie dient bei der Annahme der Begrenzung der Anfragen und steht wie bei jedem Aufruf im Zugriffsprotokoll des Servers. JavaScript-Fehler bewahrt Monitorio 90 Tage auf. Verlauf und Einstellungen findest du im Projekt unter „Statistiken → JavaScript-Fehler“.
Nein, nur ein kleines Skript in der Storefront. Unser Plugin emz/monitorio kann es ausliefern, wenn es dafür konfiguriert ist. Ebenso kannst du die beiden Zeilen aus der Einrichtungsansicht von Hand in den <head> jeder Seite setzen. Ohne Skript kommen keine Daten, und die Alarme bleiben still.
Er ist kein Geheimnis und muss keins sein: Er steht zwangsläufig im Quelltext, weil das Skript im Browser läuft, und ordnet eingehende Fehler nur deinem Projekt zu. Wer ihn abschreibt, kann keine Daten lesen und in kein anderes Projekt schreiben. Was schützt, ist die Herkunftsprüfung: Angenommen wird nur, was von einer deiner Shop-Domains kommt; Meldungen von anderen Adressen landen in einer gedeckelten Warteliste und lösen keinen Alarm aus. Den Schlüssel zu erneuern lohnt deshalb selten und kostet Fehlerdaten, bis die Storefront den neuen Einbau-Code ausliefert.
Zu jedem Fehler Fehlertyp, Meldung, Stack, Skript-Datei mit Zeilenangabe, die Seiten-URL ohne Query-String und den Viewport, dazu – falls es einen gab – den zuletzt fehlgeschlagenen Netzwerk-Aufruf mit Methode, Adresse ohne Query-String und Status. Den User-Agent liest Monitorio aus der Anfrage. Beim Einbau über das Plugin kommen Sales-Channel, Seitenbereich und Theme-Build hinzu; außerdem zählt das Skript Seitenaufrufe. Die Anfrage geht ohne Cookies raus. Mit den Fehlerdaten speichert Monitorio keine IP-Adresse; sie dient bei der Annahme der Begrenzung der Anfragen und steht wie bei jedem Aufruf im Zugriffsprotokoll des Servers. JavaScript-Fehler bewahrt Monitorio 90 Tage auf.
In Produktion liefert Shopware das JavaScript minifiziert aus, dann steht dort etwa all.js:1:284736 statt eines lesbaren Pfads. Das ist keine Fehlfunktion: Die Aussage tragen dann die Meldung, die betroffenen Seiten und die Häufigkeit – nicht die Zeilennummer.
Weil ein Dauerproblem sonst täglich erneut melden würde – für den Bestand ist die Fehlerliste da, nicht der Alarm. Kommt eine schon entwarnte Gruppe zurück, meldet „JavaScript-Fehler ist zurück“. Steigt die Fehlerrate der Storefront je Seitenaufruf deutlich über das Übliche – voreingestellt auf das Dreifache des 7-Tage-Schnitts –, meldet „JavaScript-Fehlerrate auffällig“.
Ja, die Überwachung ist für Shopware-6- und Website-Projekte verfügbar. Bei Shopware-Projekten mit hinterlegten API-Zugangsdaten holt Monitorio die Domains aller Sales Channels selbst. Bei einem Website-Projekt zählen die Projekt-URL und die Domains, die du von Hand pflegst.
Nach 5 Minuten kommen die ersten Messwerte – und du schläfst wieder durch, während Monitorio die Shops im Auge behält.