Website Monitoring für Onlineshops und Portale: Uptime-Checks, synthetische Transaktionen und Real User Monitoring

Website Monitoring zeigt Ihnen, ob Ihr Onlineshop oder Kundenportal erreichbar, schnell und funktionsfähig ist, bevor Ihre Kundschaft es Ihnen mitteilt. Für ein Unternehmen, das über den Browser Umsatz macht, ist „die Seite läuft“ keine einzelne Aussage: Die Startseite kann HTTP 200 liefern, während der Login scheitert, die Suche leer bleibt oder der Bezahlschritt in einen Timeout läuft, weil ein Zahlungsdienstleister Probleme hat.

Dieser Leitfaden erklärt die drei Ebenen, mit denen Sie eine Webseite überwachen sollten: Uptime-Checks, mehrstufige synthetische Transaktionen und Real User Monitoring. Er behandelt Prüfstandorte und Intervalle, SSL/TLS-Zertifikate, Domains und DNS, Performance-Budgets und Core Web Vitals, Drittanbieter-Skripte, die Vermeidung von Fehlalarmen, Statusseiten und die Frage, was Verfügbarkeitsprozente in Minuten bedeuten. Am Ende finden Sie eine Tabelle der Check-Typen und eine Checkliste zum Kopieren.

Drei Ebenen: Uptime-Checks, synthetische Transaktionen und Real User Monitoring

Jede Ebene beantwortet eine andere Frage, keine ersetzt die anderen.

Uptime- und HTTP-Checks

Ein Uptime-Check sendet von einem externen Standort eine Anfrage an eine URL und wertet die Antwort aus: Statuscode, Antwortzeit, optional ein Stichwort im Inhalt oder ein Header. Das ist klassisches Black-Box-Monitoring: Es kennt Ihre Interna nicht, sieht aber, was die Außenwelt sieht. Uptime Monitoring ist günstig, läuft im Minutentakt und bildet die Grundlage, um die Verfügbarkeit zu messen. Seine Grenze: Es prüft eine einzelne Anfrage. Eine Seite, die lädt, aber eine Fehlermeldung zeigt, oder ein Checkout, der nach dem zweiten Schritt abbricht, fällt nicht auf.

Zwei Ergänzungen machen HTTP-Checks deutlich aussagekräftiger: Prüfen Sie Inhalte (etwa einen Produktnamen oder den Text „In den Warenkorb“) statt nur den Statuscode, und überwachen Sie einen Health-Endpunkt, der Abhängigkeiten wie Datenbank, Suche und Cache prüft – nicht nur, ob der Webserver antwortet.

Mehrstufige synthetische Transaktionen

Synthetisches Monitoring spielt geskriptete Nutzerpfade in einem echten Browser ab: Startseite öffnen, Produkt suchen, in den Warenkorb legen, anmelden, Checkout bis zum Bezahlschritt starten. Jeder Schritt hat Prüfungen und Zeitmessungen. So erkennen Sie fehlerhaftes JavaScript, fehlgeschlagene API-Aufrufe hinter der Oberfläche, Probleme mit Sessions oder einen Suchindex, der leere Ergebnisse liefert. Skripten Sie zuerst die Pfade, mit denen der Shop Geld verdient. Das synthetische Monitoring von Obseria führt solche Browser- und API-Checks aus mehreren Regionen aus.

Bewährte Regeln: Verwenden Sie eigene Testkonten und Testartikel, brechen Sie vor einer echten Belastung ab (oder nutzen Sie die Sandbox des Zahlungsanbieters), markieren Sie synthetischen Traffic, damit er nicht in Webanalyse und Conversion-Reports landet, und versionieren Sie die Skripte gemeinsam mit dem Code der Webseite.

Real User Monitoring

Real User Monitoring (RUM) erfasst Ladezeiten und Fehler aus den Browsern echter Besucherinnen und Besucher. Es zeigt, was synthetische Checks nicht sehen: Performance in langsamen Mobilnetzen, bestimmte Browser oder Geräte mit Fehlern, regionale Probleme und den langen Schwanz an Seiten, die niemand geskriptet hat. RUM braucht Traffic und ist daher nachts und auf wenig besuchten Seiten schwach – genau dort helfen synthetische Checks. Zusammen bilden beide Ebenen das sogenannte Digital Experience Monitoring.

Check-Typen: was sie erkennen und wie oft sie laufen sollten

Die folgende Tabelle ist ein Ausgangspunkt für einen typischen Onlineshop oder ein Portal. Die Intervalle sind Beispiele; passen Sie sie an Ihren Traffic, den Umsatz pro Minute und die Kosten der Checks an.

Check-Typ	Was er erkennt	Empfohlenes Intervall (Beispiel)
HTTP/HTTPS-Uptime-Check (Startseite, wichtige Landingpages)	Ausfälle, 5xx-Fehler, Timeouts, langsame Antworten, falsche Weiterleitungen	Jede Minute aus mindestens 3 Standorten
Stichwort- bzw. Inhaltsprüfung	Fehlerseiten mit Status 200, leere Templates, vergessene Wartungsseiten	Alle 1–5 Minuten
API- bzw. Health-Endpunkt	Ausgefallene Backend-Abhängigkeiten (Datenbank, Suche, Cache, Authentifizierung)	Jede Minute
Synthetischer Pfad: Login	Defekte Anmeldung, SSO oder Session-Verwaltung	Alle 5 Minuten
Synthetischer Pfad: Suche und Produktseite	Leere Suchergebnisse, fehlerhafte Produktdaten, JavaScript-Fehler	Alle 5–10 Minuten
Synthetischer Pfad: Warenkorb und Checkout bis zur Zahlung	Defekter Checkout, Fehler bei der Weiterleitung zum Zahlungsanbieter, falsche Versand- oder Steuerberechnung	Alle 5 Minuten
SSL/TLS-Zertifikat	Ablaufende oder ungültige Zertifikate, unvollständige Kette, falscher Hostname	Täglich; Warnung 30, 14 und 7 Tage vor Ablauf
Domain-Ablauf	Domains, deren Registrierung ausläuft	Täglich; Warnung 60 und 30 Tage vor Ablauf
DNS-Check	Falsche oder fehlende Einträge, unerwartete Änderungen, Resolver-Probleme	Alle 5 Minuten
Heartbeat für geplante Jobs (Feeds, Exporte, Sitemaps)	Jobs, die unbemerkt nicht mehr laufen	Erwartetes Job-Intervall plus Karenzzeit
Real User Monitoring	Core Web Vitals, JavaScript-Fehler, langsame Regionen, Geräte und Browser	Kontinuierlich (alle oder gesampelte Sitzungen)

Die Heartbeat-Zeile wird oft vergessen. Produktfeeds für Marktplätze, Preisexporte und nächtliche Importe haben keine URL, die man prüfen könnte – sie melden sich stattdessen selbst. Das Prinzip beschreibt unser Lexikonartikel zum Heartbeat-Monitoring.

Prüfstandorte und Intervalle

Prüfen Sie von dort, wo Ihre Kundschaft sitzt. Ein Shop, der in Deutschland, Österreich und der Schweiz verkauft, braucht mindestens zwei bis drei Standorte in Mitteleuropa; verkaufen Sie auch nach Großbritannien oder in die USA, kommen dort Standorte hinzu. Checks aus nur einem Rechenzentrum melden dessen Netzwerkprobleme als Ihren Ausfall.

Das Intervall ist eine Abwägung zwischen Erkennungszeit und Kosten bzw. Rauschen. Bei einem Minutentakt und Bestätigung durch einen zweiten Standort wissen Sie von einem harten Ausfall in der Regel nach zwei bis drei Minuten. Bei 15 Minuten kann ein Ausfall eine Viertelstunde unbemerkt bleiben – für einen gut besuchten Shop ein spürbarer Verlust. Browserbasierte Pfade sind teurer als HTTP-Checks. Ein gängiges Muster lautet daher: HTTP-Checks jede Minute, kritische Pfade alle fünf Minuten, weitere Pfade alle 15 bis 30 Minuten.

Überwachen Sie nicht nur die Erreichbarkeit, sondern auch die Antwortzeit. Messen Sie die Zeit bis zum ersten Byte (TTFB) und die Gesamtdauer je Schritt, und alarmieren Sie bei anhaltender Verschlechterung, nicht bei einem einzelnen langsamen Messwert.

SSL/TLS-Zertifikate, Domain-Ablauf und DNS

Einige der unangenehmsten Ausfälle haben gar nichts mit Code zu tun. Ein abgelaufenes Zertifikat lässt Browser eine ganzseitige Warnung anzeigen; für die meisten Besucher ist das gleichbedeutend mit einem Ausfall. Automatische Verlängerung senkt das Risiko, beseitigt es aber nicht: Verlängerungen scheitern an geänderten DNS-Einträgen, Firewall-Regeln, Rate Limits oder an einem Zertifikat, das nur auf einem von zwei Load Balancern installiert wurde.

• Zertifikate: Prüfen Sie jeden öffentlichen Hostnamen, auch API-, CDN-, Bild- und Callback-Domains für Zahlungen. Kontrollieren Sie Ablaufdatum, Vollständigkeit der Kette und Hostnamen. Warnen Sie frühzeitig und erneut kurz vor Ablauf.
• Domains: Überwachen Sie den Registrierungsablauf Ihrer Hauptdomain und aller Domains, die in E-Mails, Weiterleitungen und Kampagnen-Landingpages genutzt werden. Stellen Sie sicher, dass beim Registrar ein gültiges Zahlungsmittel hinterlegt ist und die verantwortliche Person noch im Unternehmen arbeitet.
• DNS: Prüfen Sie, ob A/AAAA-, CNAME- und MX-Einträge über mehrere Resolver die erwarteten Werte liefern, und alarmieren Sie bei unerwarteten Änderungen. Eine falsche DNS-Änderung kann eine Webseite wegen Caching über Stunden unerreichbar machen – schnelles Erkennen zählt.

Performance-Budgets und Core Web Vitals

Ein langsamer Shop ist ein teilweise defekter Shop. Performance-Budgets machen aus „schnell genug“ überwachbare Zahlen, zum Beispiel eine maximale Seitengröße, eine Obergrenze für Drittanbieter-Anfragen oder eine maximale TTFB für Produktseiten. Googles Core Web Vitals liefern den nutzerzentrierten Teil eines solchen Budgets. Laut web.dev werden die Schwellenwerte am 75. Perzentil der Seitenaufrufe bewertet, getrennt nach Mobilgeräten und Desktop:

Metrik	Was sie misst	Gut	Schlecht
Largest Contentful Paint (LCP)	Laden: wann das größte sichtbare Element dargestellt ist	≤ 2,5 s	> 4 s
Interaction to Next Paint (INP)	Reaktionsfähigkeit auf Klicks, Tippen und Tastatureingaben	≤ 200 ms	> 500 ms
Cumulative Layout Shift (CLS)	Visuelle Stabilität: unerwartete Layoutverschiebungen	≤ 0,1	> 0,25

Werte zwischen „gut“ und „schlecht“ gelten als „verbesserungswürdig“. Labormessungen aus synthetischen Checks eignen sich, um Verschlechterungen nach einem Deployment zu erkennen. Maßgeblich für Google und für Ihre Kundschaft sind aber die Felddaten echter Nutzer. Beobachten Sie beides und schlüsseln Sie RUM-Daten nach Seitentyp auf (Start-, Kategorie-, Produktseite, Warenkorb, Checkout), weil sich deren Performance deutlich unterscheidet.

Drittanbieter-Skripte und Zahlungsdienstleister

Eine typische Shopseite lädt Tag-Manager, Webanalyse, Consent-Banner, Chat-Widgets, Bewertungs-Widgets, A/B-Testing-Tools und Empfehlungssysteme. Jedes davon kann das Rendern verlangsamen, Interaktionen blockieren oder Fehler werfen – und deren Deployments steuern Sie nicht. Zahlungsdienstleister, Adressprüfung und Versand-APIs sind noch kritischer: Fallen sie aus, steht Ihr Checkout, obwohl Ihre eigenen Server einwandfrei laufen.

• Erfassen Sie alle Drittanbieter-Domains, die Ihre Seiten laden, und benennen Sie für jede eine verantwortliche Person.
• Messen Sie per RUM den Einfluss von Drittanbieter-Skripten auf LCP, INP und die JavaScript-Fehlerrate.
• Nehmen Sie die Weiterleitung oder das eingebettete Formular des Zahlungsanbieters in den Checkout-Pfad auf, möglichst mit Sandbox-Zugangsdaten.
• Beobachten Sie die Statusseiten oder Status-APIs kritischer Anbieter und gleichen Sie deren Störungen mit Ihren eigenen Checks ab.
• Laden Sie nicht notwendige Skripte asynchron und legen Sie fest, was bei einem Fehler passiert, damit ein defektes Chat-Widget nicht den Bestellbutton blockiert.

Fehlalarme vermeiden

Ein Monitoring, das Menschen grundlos weckt, wird ignoriert, wenn es darauf ankommt. Die meisten Fehlalarme beim Website Monitoring entstehen durch kurze Netzwerkstörungen, Probleme an einzelnen Standorten und zu strenge Timeouts.

• Bestätigung aus mehreren Standorten: Alarmieren Sie erst, wenn zum Beispiel mindestens zwei von drei Standorten den Fehler sehen. Ein einzelner fehlerhafter Standort deutet eher auf ein Netzwerkproblem dort hin.
• Wiederholung vor dem Alarm: Führen Sie einen fehlgeschlagenen Check sofort ein- bis zweimal erneut aus und alarmieren Sie bei aufeinanderfolgenden Fehlern, nicht bei einem einzelnen.
• Realistische Timeouts und Schwellenwerte: Leiten Sie Antwortzeit-Grenzen aus gemessenen Perzentilen ab, nicht aus Wunschwerten.
• Wartungsfenster: Pausieren oder kennzeichnen Sie Checks während geplanter Deployments und Wartungen.
• Routing nach Schweregrad: Ein defekter Checkout alarmiert die Rufbereitschaft, eine langsame Blogseite erzeugt ein Ticket.
• Verknüpfung mit Telemetrie: Verbinden Sie fehlgeschlagene synthetische Checks mit Backend-Traces und Logs, damit das Team die Ursache sieht und nicht nur das Symptom.

Was Verfügbarkeitsprozente in Minuten bedeuten

Verfügbarkeitsziele in Verträgen und SLAs klingen ähnlich, unterscheiden sich in der Praxis aber erheblich. Die Tabelle geht von einem durchschnittlichen Monat mit 30,4 Tagen aus (365 Tage geteilt durch 12, das entspricht 43.776 Minuten) und von einem Jahr mit 365 Tagen (525.600 Minuten):

Verfügbarkeit	Erlaubter Ausfall pro Monat	Erlaubter Ausfall pro Jahr
99 %	≈ 437,8 Min. (rund 7 Std. 18 Min.)	≈ 87,6 Std. (rund 3,65 Tage)
99,5 %	≈ 218,9 Min. (rund 3 Std. 39 Min.)	≈ 43,8 Std.
99,9 %	≈ 43,8 Min.	≈ 8 Std. 46 Min.
99,95 %	≈ 21,9 Min.	≈ 4 Std. 23 Min.
99,99 %	≈ 4,4 Min.	≈ 52,6 Min.

Zwei Punkte entscheiden darüber, wie aussagekräftig solche Zahlen sind. Erstens: Was gilt als Ausfall – nur die vollständige Nichterreichbarkeit oder auch ein defekter Checkout oder eine Antwortzeit über einem Grenzwert? Zweitens: Wie wird gemessen – als Anteil fehlgeschlagener Prüfintervalle, bestätigt von wie vielen Standorten? Bei Checks im Minutentakt lässt ein Ziel von 99,99 % nur etwa vier fehlgeschlagene Intervalle pro Monat zu; die Messmethode entscheidet also mit darüber, ob Sie das Ziel erreichen.

Statusseiten und Kommunikation

Wenn etwas ausfällt, wollen Kundschaft und Support drei Dinge wissen: Ist das Problem bekannt, was ist betroffen und wann kommt das nächste Update? Eine Statusseite beantwortet diese Fragen an einer Stelle und entlastet den Support während eines Vorfalls. Gliedern Sie die Komponenten so, wie Ihre Kundschaft denkt (Shop, Checkout, Kundenkonto, API), veröffentlichen Sie das erste Update innerhalb weniger Minuten, aktualisieren Sie in festen Abständen – auch wenn es nichts Neues gibt – und veröffentlichen Sie danach eine kurze Zusammenfassung. Betreiben Sie die Statusseite unabhängig von Ihrer Hauptinfrastruktur, damit sie erreichbar bleibt, wenn der Shop es nicht ist.

Checkliste: Website Monitoring für Onlineshops

Kopieren Sie diese Checkliste in Ihr Wiki oder Ticketsystem und arbeiten Sie sie ab:

CHECKLISTE WEBSITE MONITORING FÜR ONLINESHOPS
[ ] HTTP-Checks jede Minute für Start-, Kategorie-, Produkt- und Checkout-URLs
[ ] Inhaltsprüfung (Stichwort) auf wichtigen Seiten, nicht nur Statuscodes
[ ] Health-Endpunkt, der Datenbank, Suche, Cache und Login prüft
[ ] Synthetische Pfade: Login, Suche, Produktseite, Warenkorb, Checkout bis Zahlung
[ ] Synthetischer Traffic markiert und aus der Webanalyse ausgeschlossen
[ ] Prüfstandorte in jeder wichtigen Verkaufsregion (mind. 3)
[ ] Alarm erst nach Wiederholung + Bestätigung durch 2 von 3 Standorten
[ ] TLS-Zertifikatsprüfung für alle öffentlichen Hostnamen (30/14/7 Tage)
[ ] Domain-Ablaufprüfung für alle Domains (60/30 Tage)
[ ] DNS-Prüfung und Alarm bei unerwarteten Änderungen
[ ] Heartbeats für Feeds, Exporte, Importe und Sitemap-Jobs
[ ] RUM mit Core Web Vitals je Seitentyp (LCP, INP, CLS am p75)
[ ] Performance-Budget definiert und nach jedem Deployment geprüft
[ ] Inventar der Drittanbieter-Skripte mit Verantwortlichen
[ ] Status von Zahlungs- und Versanddienstleistern überwacht
[ ] Alarm-Routing nach Schweregrad und Wartungsfenster eingerichtet
[ ] Ausfalldefinition und Messmethode für das SLA dokumentiert
[ ] Statusseite unabhängig gehostet, Update-Rhythmus vereinbart

Wie Obseria unterstützt

Obseria verbindet externes Website Monitoring mit der Telemetrie aus Ihrem Backend: Ein fehlgeschlagener Check führt direkt zu den Traces, Logs und der Topologie dahinter. Synthetische Checks, Real User Monitoring und Statusseiten laufen auf derselben OpenTelemetry-nativen Plattform wie Ihre Metriken, Logs und Traces – mit Datenhaltung in der EU und nutzungsbasierten Preisen.

• Browser- und API-Checks aus mehreren Regionen mit Wiederholungen und Bestätigung durch mehrere Standorte.
• Real User Monitoring mit Core Web Vitals und JavaScript-Fehlern je Seitentyp.
• Statusseiten und Incident Management, verbunden mit denselben Alarmen.
• Obseria Intelligence verknüpft einen defekten Checkout mit dem Backend-Service, dem Deployment oder der Drittanbieter-Abhängigkeit, die ihn verursacht hat.

Die ersten Checks für Ihren Shop richten Sie in einer kostenlosen Testphase ein.