Statuscode 200 und trotzdem kaputt: Monitoring richtig machen
Das Dashboard ist grün, das Postfach voll
Stellen Sie sich einen Dienstagmorgen vor. Im Monitoring steht alles auf Grün, jede Minute wird die Startseite abgefragt, jede Minute kommt die Antwort „200 OK". Gleichzeitig trudeln im Postfach des Vertriebs Beschwerden ein: Die Bestellung lässt sich nicht abschließen, das Anfrageformular meldet einen Fehler, auf der Produktseite fehlen die Preise. Wer ist hier im Irrtum, das Werkzeug oder die Kunden?
Keiner von beiden. Das Werkzeug misst korrekt, was es messen soll: Der Server hat geantwortet, und zwar mit einem Code, der „Anfrage erfolgreich verarbeitet" bedeutet. Nur ist das eben nicht dasselbe wie „Die Website tut, was sie tun soll". Auf diese Lücke weist der Ratgeber von Fabian Deitelhoff bei Golem.de hin. Sein Ausgangspunkt ist genau diese Erfahrung: Das Dashboard zeigt Grün, und trotzdem kommen die Beschwerden. Website-Monitoring soll solche Überraschungen verhindern, doch auch die Werkzeuge selbst haben blinde Flecken.
Für uns als Agentur, die täglich Websites und Shops von Mittelständlern betreut, ist das ein Alltagsthema. Und es ist ein Thema, bei dem sich mit relativ wenig Aufwand viel Ärger vermeiden lässt, wenn man die Denkweise ändert: weg von „Ist der Server erreichbar?", hin zu „Kann ein Kunde sein Ziel erreichen?".
Was ein Statuscode wirklich aussagt
HTTP-Statuscodes sind eine Art Kurzmitteilung zwischen Server und Browser. Die Familie der 2xx-Codes bedeutet grob: Die Anfrage ist angekommen und wurde technisch korrekt beantwortet. Die 200 ist der Normalfall. Daneben kennen die meisten Menschen die 404 („Seite nicht gefunden") oder die 500 („Serverfehler").
Das Problem: Der Code beschreibt nur die Ebene der Übertragung. Er sagt nichts darüber, was in der Antwort steht. Eine Seite kann mit 200 ausgeliefert werden und trotzdem inhaltlich kaputt sein. Einige Beispiele, wie das in der Praxis aussieht:
- Eine Seite liefert zwar 200, zeigt aber nur eine leere weiße Fläche, weil ein Skript abgebrochen ist.
- Ein Shop gibt eine freundlich gestaltete Fehlermeldung aus („Hoppla, da ist etwas schiefgelaufen"), die technisch als erfolgreiche Seite gilt.
- Ein Template ist nach einem Update defekt, sodass Produkte ohne Preise, Bilder oder Kaufbutton erscheinen.
- Die Startseite ist in Ordnung, aber die Seite dahinter, auf der Kunden bezahlen, läuft in einen Fehler.
- Ein Cache liefert eine alte, veraltete oder fehlerhafte Version aus, während im Hintergrund etwas nicht mehr stimmt.
In all diesen Fällen ist der Statuscode unauffällig. Ein klassischer Verfügbarkeitstest, der nur den Code prüft, meldet dann pflichtschuldig: alles in Ordnung. Das ist kein Fehler des Tests, sondern eine Folge seiner Konstruktion. Er beantwortet eine sehr enge Frage, und die Verantwortlichen lesen die Antwort als Aussage über das Gesamtsystem.
Man kann es mit einem Ladengeschäft vergleichen. Ein Passant, der vorbeigeht, sieht: Licht an, Tür offen. Das entspricht dem Statuscode 200. Ob die Kasse funktioniert, ob die Regale gefüllt sind und ob jemand bedient, erfährt er dadurch nicht.
Wo klassisches Monitoring blinde Flecken hat
Der Ratgeber betont, dass auch die Werkzeuge selbst Grenzen haben. Das ist ein wichtiger Gedanke, denn viele Unternehmen haben „ein Monitoring" eingerichtet und fühlen sich damit auf der sicheren Seite. Aus unserer Erfahrung lassen sich die typischen Schwachstellen in einige Gruppen einteilen. Dabei ordnen wir ein, ohne uns auf konkrete Zahlen aus dem Artikel zu stützen, denn die liegen uns nicht vor.
Nur die Startseite wird geprüft. Das ist der häufigste Fall. Die Startseite ist meist stabil, oft sogar aus dem Cache bedient. Die Probleme entstehen dort, wo Logik im Spiel ist: bei der Suche, beim Warenkorb, bei der Kasse, beim Login, beim Kontaktformular.
Nur der Statuscode wird geprüft. Wie oben beschrieben: Eine inhaltlich kaputte Seite besteht den Test trotzdem.
Der Test läuft von einem Standort und ohne Nutzerverhalten. Ein Werkzeug, das von einem Rechenzentrum aus alle paar Minuten eine Adresse abruft, verhält sich anders als ein Kunde mit Smartphone, Cookie-Banner, Werbeblocker und einer Verbindung im Zug.
Drittanbieter bleiben unsichtbar. Moderne Websites hängen an vielen externen Diensten: Zahlungsanbieter, Versanddienstleister, Kartendienste, Bewertungsplattformen, Newsletter-Systeme, Consent-Tools. Fällt einer davon aus oder ändert sich, kann die eigene Seite mit 200 antworten und trotzdem eine Kernfunktion verlieren.
Alarmmüdigkeit. Das ist das Gegenstück zum falschen Frieden. Wer zu viele oder zu empfindliche Alarme eingerichtet hat, lernt irgendwann, sie zu ignorieren. Dann geht auch der berechtigte Alarm unter.
Keiner fühlt sich zuständig. Selbst das beste Monitoring nützt wenig, wenn niemand definiert hat, wer bei einem Alarm reagiert, bis wann und mit welchem Ziel. Dieses organisatorische Loch ist in kleinen und mittleren Unternehmen häufiger als das technische.
Diese Liste ist keine Kritik an einzelnen Produkten. Sie beschreibt, wo in der Praxis Lücken entstehen, wenn Überwachung als einmalige Einrichtungsaufgabe verstanden wird statt als laufende Beschreibung dessen, was für das Geschäft wichtig ist.
Warum das gerade für den Mittelstand teuer wird
Ein Konzern hat Betriebsteams, die rund um die Uhr auf Dashboards schauen, und Prozesse, die Auffälligkeiten einsammeln. Beim Mittelständler sieht die Realität anders aus. Die Website wird nebenbei betreut, vielleicht von einer Person im Marketing, einem externen Dienstleister oder dem Geschäftsführer selbst. Das Monitoring ist ein kostenloser Dienst, der einmal eingerichtet wurde und seither Mails verschickt, die niemand mehr liest.
Wenn dann etwas kaputtgeht, ohne dass ein Alarm kommt, passiert Folgendes: Die Information erreicht das Unternehmen auf dem schlechtesten aller Wege, nämlich über den Kunden. Und der Kunde meldet sich oft gar nicht. Er bricht den Kauf ab, geht zum Wettbewerber oder denkt sich, dass die Firma offenbar nicht mehr aktiv ist. Die Beschwerden, die im Postfach landen, sind nur die Spitze. Wer sich die Mühe macht zu schreiben, ist eher die Ausnahme.
Der Schaden hat dabei mehrere Ebenen:
1. Direkter Umsatzverlust. Jede Stunde, in der der Checkout klemmt, ist eine Stunde ohne Bestellungen. Bei einem Shop mit stetigem Auftragseingang ist das sofort spürbar, bei einem Dienstleister mit Anfrageformular eher schleichend, aber nicht weniger real.
2. Verlorene Anfragen. Ein Formular, das stillschweigend keine Mails mehr zustellt, ist besonders tückisch. Der Interessent denkt, er habe sich gemeldet. Das Unternehmen weiß nichts davon. Aus der Funkstille wird im schlimmsten Fall Misstrauen.
3. Vertrauensschaden. Fehlerseiten, fehlende Preise oder kaputte Layouts wirken unprofessionell, auch wenn sie nach kurzer Zeit behoben sind.
4. Sichtbarkeit. Wenn Suchmaschinen über längere Zeit defekte oder leere Seiten sehen, kann das die Wahrnehmung der Seite beeinträchtigen. Wie stark, hängt vom Einzelfall ab, aber es ist ein Risiko, das man nicht ohne Not eingehen sollte.
5. Rechtliche und organisatorische Nebenwirkungen. Fällt etwa ein Einwilligungsbanner aus oder verschwindet ein Pflichtlink im Footer, ohne dass es jemand merkt, entsteht ein Problem, das mit Technik zunächst nichts zu tun hat.
Besonders ärgerlich ist, dass solche Fehler oft nach Änderungen auftreten, die für sich genommen harmlos wirkten: ein Plugin-Update, ein neues Theme-Detail, eine geänderte Einstellung beim Zahlungsanbieter, ein Zertifikatswechsel. Der Server läuft weiter, die Seite antwortet, nur ein Baustein dahinter ist weggebrochen.
Von „ist erreichbar" zu „funktioniert": die Denkweise wechseln
Der zentrale Gedanke ist einfach, auch wenn die Umsetzung Sorgfalt braucht: Überwachen Sie nicht die Technik, sondern die Aufgaben Ihrer Website. Fragen Sie nicht „Antwortet der Server?", sondern „Kann ein Besucher das tun, wofür wir die Seite betreiben?".
Dazu hilft eine kleine Übung, die wir mit Kunden gern in einer halben Stunde machen. Schreiben Sie auf, was Ihre Website im Idealfall pro Tag leisten muss. Bei einem Shop könnte die Liste so aussehen:
- Ein Besucher findet ein Produkt über die Suche oder Kategorie.
- Er legt es in den Warenkorb.
- Er gelangt zur Kasse und kann Versand- und Zahlungsart wählen.
- Er schließt die Bestellung ab und erhält eine Bestätigung.
Bei einem Dienstleister oder Handwerksbetrieb eher so:
- Ein Besucher ruft die Leistungsseite auf und sieht Telefonnummer und Kontaktmöglichkeiten.
- Er füllt das Formular aus und sendet es ab.
- Die Anfrage kommt tatsächlich im Postfach oder im CRM an.
Jeder dieser Schritte ist ein potenzieller Prüfpunkt. Und jeder dieser Prüfpunkte lässt sich so beschreiben, dass ein Werkzeug ihn nachstellen kann. Das ist der Unterschied zwischen einem reinen Erreichbarkeitstest und einer Überwachung, die den tatsächlichen Nutzen im Blick hat. Manche sprechen dabei von synthetischem Monitoring oder von Transaktionstests: Ein automatisierter Besucher durchläuft in regelmäßigen Abständen die wichtigen Wege und schlägt Alarm, wenn ein Schritt nicht gelingt.
Was sich sinnvoll überwachen lässt
Wir unterscheiden bei Kunden gern drei Ebenen, die aufeinander aufbauen.
Ebene 1: Inhalte prüfen statt nur den Code
Die einfachste Verbesserung kostet fast nichts. Statt nur den Statuscode zu prüfen, lassen Sie das Werkzeug zusätzlich nach einem festen Textbaustein suchen, der auf der Seite stehen muss. Das kann ein Satz im Footer sein, der Name eines Produkts, der Schriftzug des Kaufbuttons oder ein Teil der Telefonnummer. Fehlt der Text, ist die Seite offenbar nicht in Ordnung, auch wenn der Code 200 lautet.
Genauso nützlich ist die umgekehrte Prüfung: Alarm schlagen, wenn ein Text erscheint, der nicht erscheinen sollte, etwa „Fehler", „Wartungsmodus" oder die typische Meldung einer Datenbank, die nicht erreichbar ist. Viele Systeme zeigen im Problemfall eine gestaltete Fehlerseite. Wenn Sie deren Wortlaut kennen, können Sie gezielt danach suchen.
Eine Ergänzung: Prüfen Sie nicht nur die Startseite, sondern eine Auswahl repräsentativer Seiten, zum Beispiel eine Produktseite, eine Kategorie, eine Leistungsseite und das Impressum.
Ebene 2: Formulare und Checkout durchspielen
Hier wird es wertvoll. Ein automatisierter Test füllt das Kontaktformular mit Testdaten aus, sendet es ab und prüft, ob die Erfolgsmeldung erscheint. Noch besser ist es, zusätzlich zu prüfen, ob die Nachricht wirklich ankommt, zum Beispiel in einem dafür eingerichteten Testpostfach. So entdecken Sie auch den Fall, dass die Seite „Danke für Ihre Nachricht" zeigt, die Mail aber nie zugestellt wird, etwa weil der Mailversand nicht mehr funktioniert.
Beim Shop gilt dasselbe für den Bestellweg. Ein Test legt einen Artikel in den Warenkorb, geht bis zur Kasse und bricht dort kontrolliert ab, bevor echtes Geld fließt, oder nutzt den Testmodus des Zahlungsanbieters. Wichtig dabei: Testbestellungen müssen klar erkennbar sein und dürfen weder Lagerbestand noch Buchhaltung durcheinanderbringen. Das sollte vorher sauber geplant werden, vor allem wenn eine Warenwirtschaft angebunden ist. Läuft der Shop beispielsweise über eine Anbindung an JTL, lohnt ein Blick auf unser JTL-Hosting, weil dort Shop, Schnittstelle und Warenwirtschaft ohnehin zusammen betrachtet werden müssen.
Ein Hinweis zur Vorsicht: Solche Tests sind kein Selbstzweck. Sie sollten nur die wenigen Wege abdecken, an denen wirklich Geld oder Anfragen hängen. Wer zwanzig Abläufe überwacht, pflegt am Ende zwanzig potenzielle Fehlalarme.
Ebene 3: Das Umfeld im Blick behalten
Zur dritten Ebene gehört alles, was nicht direkt auf der eigenen Seite passiert, aber deren Funktion beeinflusst:
- Zertifikate: Läuft das SSL-Zertifikat ab, zeigen Browser Warnungen, und viele Besucher drehen sofort um. Eine Ablaufüberwachung mit Vorwarnzeit gehört zum Pflichtprogramm.
- Domains und DNS: Ein vergessener Domain-Renewal oder eine falsch gesetzte Namensserver-Einstellung kann alles lahmlegen.
- Mailversand: Funktionieren SPF, DKIM und DMARC, kommen Bestellbestätigungen im Postfach an und nicht im Spam?
- Ladezeit: Eine Seite, die zwar antwortet, aber zehn Sekunden braucht, ist für viele Nutzer faktisch ausgefallen.
- Externe Dienste: Zahlungsanbieter, Versand, Kartendienste und Skripte von Drittanbietern. Zumindest sollten Sie wissen, welche es gibt und wo deren Statusseiten zu finden sind.
Diese Ebene klingt nach viel, aber ein Großteil davon lässt sich mit einer einmaligen Bestandsaufnahme erledigen. Eine strukturierte Prüfung, wie wir sie im Website-Audit durchführen, deckt solche Abhängigkeiten oft schon beim ersten Durchgang auf und zeigt, was im Alltag unbemerkt mitläuft.
Wenn der Alarm kommt: Wer reagiert?
Ein Test, der Fehler erkennt, ist nur die halbe Lösung. Mindestens genauso wichtig ist die Frage, was danach passiert. Bei unseren Kundengesprächen zeigt sich immer wieder dasselbe Muster: Alarmmails gehen an eine allgemeine Adresse, die niemand mehr beobachtet, oder an einen Mitarbeiter, der längst eine andere Rolle hat.
Ein tragfähiger Ablauf muss nicht kompliziert sein. Er braucht vier Antworten:
1. Wer wird benachrichtigt? Mindestens zwei Personen, damit Urlaub und Krankheit kein Loch reißen.
2. Auf welchem Weg? Eine Mail im Postfach zu später Stunde wird übersehen. Für kritische Systeme eignen sich Push-Nachrichten oder SMS, für weniger kritische reicht ein gesammelter Bericht.
3. Was ist die erste Maßnahme? Eine kurze Checkliste hilft: Seite selbst aufrufen, Hoster-Status prüfen, letzte Änderung zurücknehmen, Dienstleister informieren.
4. Wann wird eskaliert? Wenn nach einer definierten Zeit nichts passiert ist, muss jemand Weiteres informiert werden.
Dazu gehört auch, die Alarmschwellen vernünftig einzustellen. Ein einzelner fehlgeschlagener Abruf muss nicht sofort jemanden aus dem Schlaf reißen. Zwei oder drei aufeinanderfolgende Fehlschläge sind meist ein besseres Signal. So bleiben Alarme selten genug, um ernst genommen zu werden.
Wer die Betreuung nicht selbst stemmen kann oder will, sollte diese Zuständigkeit vertraglich klären. Bei Managed Hosting gehört die Überwachung der Systeme und die Reaktion bei Störungen üblicherweise zum Leistungsumfang. Entscheidend ist, genau nachzufragen, was überwacht wird: nur der Server, oder auch die Funktionen, die Ihr Geschäft tragen.
Typische Fehler beim Einrichten
Aus der Praxis haben sich einige Stolperfallen herauskristallisiert, die wir immer wieder sehen.
Der Test prüft die falsche Instanz. Manche Tests rufen die Seite über einen Weg ab, der Cache oder Schutzmechanismen umgeht, und sehen damit etwas anderes als echte Besucher. Prüfen Sie so nah wie möglich an der Nutzerrealität, also über die öffentliche Adresse und mit einem Verhalten, das dem eines Browsers ähnelt.
Testdaten verschmutzen die Auswertung. Testbestellungen oder Testanfragen tauchen in Statistiken, im CRM oder in der Buchhaltung auf. Kennzeichnen Sie sie eindeutig und filtern Sie sie aus Auswertungen heraus.
Der Test wird nie aktualisiert. Wird der Shop umgebaut, ändern sich Buttons, Texte und Abläufe. Der alte Test schlägt dann plötzlich fehl, obwohl alles funktioniert, oder er prüft etwas, das es gar nicht mehr gibt. Jede größere Änderung an der Website sollte die Frage auslösen: Muss der Test angepasst werden?
Zu viel auf einmal. Wer mit zwanzig Prüfungen startet, ist nach drei Wochen von Fehlalarmen genervt. Besser: mit zwei, drei Kernabläufen beginnen und diese zuverlässig machen.
Das Monitoring läuft auf derselben Infrastruktur wie die Website. Fällt der Server aus, fällt auch der Wächter aus. Die Überwachung sollte unabhängig vom überwachten System laufen.
Sicherheit wird vergessen. Eine Website kann scheinbar normal antworten und trotzdem kompromittiert sein, etwa wenn fremde Skripte eingeschleust wurden. Ein reiner Funktionstest erkennt das nicht zuverlässig. Das ist ein Grund, Monitoring und Absicherung zusammen zu denken, wie wir es im Bereich IT-Sicherheit tun.
Was das für den Mittelstand bedeutet
Aus all dem lässt sich eine überschaubare Liste machen, die ein Mittelständler ohne eigene IT-Abteilung angehen kann. Wir empfehlen diese Reihenfolge:
1. Bestandsaufnahme der Kernfunktionen. Notieren Sie die drei bis fünf Abläufe, an denen Umsatz oder Anfragen hängen: Bestellung, Kontaktformular, Terminbuchung, Login, Angebotsanfrage. Alles andere ist zweitrangig.
2. Prüfen, was heute überwacht wird. Fragen Sie Ihren Dienstleister oder Hoster konkret: Wird nur der Statuscode geprüft oder auch der Inhalt? Welche Seiten? In welchem Intervall? Wohin gehen die Alarme? Die ehrliche Antwort ist oft aufschlussreich.
3. Inhaltsprüfungen ergänzen. Lassen Sie wichtige Seiten auf feste Textbausteine prüfen, und zwar auf solche, die da sein müssen, und auf solche, die nicht da sein dürfen.
4. Mindestens einen Ablauf durchspielen lassen. Starten Sie mit dem Wichtigsten: Kontaktformular mit Zustellprüfung oder Bestellvorgang bis zur Kasse.
5. Zertifikate, Domains und Mailversand überwachen. Diese drei Punkte verursachen regelmäßig vermeidbare Ausfälle und sind leicht zu automatisieren.
6. Zuständigkeiten festlegen. Mindestens zwei Ansprechpersonen, ein Kommunikationsweg, eine kurze Checkliste für den Ernstfall.
7. Nach jeder größeren Änderung testen. Plugin-Updates, Theme-Anpassungen, neue Zahlarten, Umzug auf einen anderen Server: Danach einmal manuell und einmal automatisiert die Kernwege prüfen.
8. Gelegentlich selbst Kunde sein. Rufen Sie Ihre Seite hin und wieder mit dem Handy auf, ohne eingeloggt zu sein, und bestellen oder schreiben Sie wie ein Fremder. Das ersetzt kein Werkzeug, deckt aber Dinge auf, die keine Automatik meldet.
9. Backups und Wiederherstellung mitdenken. Monitoring zeigt den Fehler, aber die Behebung hängt oft an einer sauberen Sicherung. Klären Sie, wie schnell Sie im Ernstfall zu einem funktionierenden Stand zurückkehren, und ob Daten im schlimmsten Fall wiederhergestellt werden können. Hilfe dazu gibt es bei Datenrettung.
Wer größere Systeme betreibt, etwa Shop und Warenwirtschaft mit mehreren Schnittstellen, sollte zusätzlich festhalten, welche Systeme voneinander abhängen. Fällt die Schnittstelle zwischen Shop und Warenwirtschaft aus, merkt der Besucher es oft gar nicht sofort, das Unternehmen dafür umso später: Bestellungen kommen nicht an, Bestände stimmen nicht mehr. Auch hier gilt: Überwachen Sie das Ergebnis, nicht nur den Prozess.
Und noch ein Wort zur Verhältnismäßigkeit. Nicht jede Website braucht ein aufwendiges Testsystem. Ein Handwerksbetrieb mit Visitenkarten-Auftritt kommt mit Inhaltsprüfung, Zertifikatsüberwachung und einem getesteten Kontaktformular sehr weit. Ein Onlineshop mit täglichen Bestellungen darf mehr investieren, weil jede Störung unmittelbar Geld kostet. Der Maßstab ist immer derselbe: Was kostet eine Stunde Ausfall der wichtigsten Funktion, und wie viel Aufwand ist angemessen, um sie zu verhindern?
Fazit: Grün ist nur eine Farbe
Ein grünes Dashboard ist beruhigend, aber es beantwortet nur die Frage, auf die es programmiert wurde. Der Ratgeber von Golem.de bringt das auf den Punkt, indem er daran erinnert, dass selbst gute Überwachung blinde Flecken hat. Für Unternehmen heißt das: Das Monitoring ist ein Werkzeug, kein Beweis. Es wird erst dann wertvoll, wenn es das misst, was für das Geschäft zählt, und wenn jemand da ist, der auf die Meldungen reagiert.
Die gute Nachricht: Der Weg dorthin ist keine große Investition. Zwei, drei sauber definierte Prüfungen für die wichtigsten Abläufe, eine Handvoll Inhaltschecks, überwachte Zertifikate und klare Zuständigkeiten decken den größten Teil der Risiken ab. Wenn Sie wissen möchten, wo Ihre eigene Seite steht, hilft ein Blick von außen. Wir sind als IT-Service Friesland für Unternehmen in der Region ansprechbar und schauen gern gemeinsam mit Ihnen darauf, was bei Ihnen wirklich überwacht wird und was nur so aussieht.
Häufige Fragen
Reicht ein kostenloser Uptime-Dienst für meine Website aus?
Für eine einfache Informationsseite ist er ein sinnvoller Anfang, weil er zumindest einen Totalausfall meldet. Er prüft aber meist nur Erreichbarkeit und Statuscode. Sobald über die Seite Umsatz oder Anfragen laufen, sollten Sie zusätzlich Inhalte und die wichtigsten Abläufe prüfen lassen.
Was bedeutet Statuscode 200 genau?
Der Code sagt, dass der Server die Anfrage erhalten und technisch erfolgreich beantwortet hat. Er sagt nichts darüber, ob die ausgelieferte Seite vollständig, korrekt oder brauchbar ist. Eine leere Seite oder eine gestaltete Fehlermeldung kann ebenfalls mit 200 kommen.
Wie oft sollte ein Checkout- oder Formulartest laufen?
Das hängt davon ab, was ein Ausfall kostet. Für einen aktiven Shop sind Abstände von wenigen Minuten bis zu einer Viertelstunde üblich, für ein Kontaktformular reicht oft eine Prüfung pro Stunde. Wichtig ist, dass die Alarme verlässlich bleiben und nicht durch Fehlalarme entwertet werden.
Können Testbestellungen meine Buchhaltung durcheinanderbringen?
Das kann passieren, wenn sie nicht sauber gekennzeichnet sind. Deshalb sollten Tests im Testmodus des Zahlungsanbieters laufen oder vor dem Bezahlschritt enden, und Testvorgänge müssen aus Auswertungen herausgefiltert werden. Bei angebundener Warenwirtschaft lohnt vorab eine kurze Abstimmung.
Wer sollte bei einem Alarm reagieren?
Mindestens zwei benannte Personen, damit Urlaub oder Krankheit keine Lücke lassen. Das kann intern jemand aus dem Team sein oder ein externer Dienstleister, wenn das vertraglich geregelt ist. Entscheidend ist, dass vorher feststeht, wer was in welcher Zeit tut.
Brauche ich Monitoring, wenn mein Hoster die Server überwacht?
Die Serverüberwachung des Hosters ist wichtig, deckt aber meist nur die technische Basis ab. Ob Ihr Kontaktformular Mails zustellt oder Ihr Warenkorb funktioniert, sieht er in der Regel nicht. Dafür brauchen Sie Prüfungen, die auf Ihre Inhalte und Abläufe zugeschnitten sind.