Monitoring für den Mittelstand: Was wirklich überwacht werden muss — und was reines Werkzeug-Theater ist

„Wir merken schon, wenn die Site weg ist — dann ruft uns ein Kunde an.“ Dieser Satz fällt in Erstgesprächen häufiger, als man denkt. Er ist menschlich nachvollziehbar und geschäftlich riskant. Der Anruf vom Kunden bedeutet nämlich: Die Site war lange genug weg, dass jemand es bemerkt hat, sich beschwerten Mühe gemacht hat und jetzt einen schlechten ersten Eindruck mit nach Hause nimmt.

Dieser Artikel erklärt, wie Monitoring im Mittelstand aussehen sollte — ohne Konzern-Pathos, ohne 200 Kennzahlen, mit klarem Fokus auf das, was geschäftlich wirklich zählt.

Was Monitoring im Mittelstand leisten muss

Vier Aufgaben, in dieser Reihenfolge:

1. Ausfälle bemerken, bevor Kunden sie melden. Die Latenz zwischen Ausfall und Kenntnis sollte unter fünf Minuten liegen, bei kritischen Geschäfts-Sites unter einer Minute.
2. Leistung beobachten, bevor sie abrutscht. Eine Site, die langsam wird, ist ein Vorbote für eine Site, die ausfällt. Wer das Abrutschen sieht, kann vorher handeln.
3. Sicherheits-Auffälligkeiten erkennen, bevor sie zum Vorfall werden. Ungewöhnliche Anmelde-Versuche, Scan-Wellen, plötzliche Traffic-Spitzen aus auffälligen Quellen — alles Frühwarn-Zeichen.
4. Geschäfts-relevante Funktionen prüfen. Es nützt nichts, wenn der Server antwortet, aber das Kontaktformular still ins Leere schickt.

Wer ein Monitoring-System aufbaut, das diese vier Aufgaben deckt, hat im Mittelstand alles, was zählt. Alles darüber hinaus ist meistens Werkzeug-Theater.

Die vier zentralen Überwachungs-Felder

1. Verfügbarkeit (Uptime)

Der einfachste und wichtigste Wert. Ein externes Monitoring-Werkzeug prüft alle 30 bis 60 Sekunden, ob die Site antwortet. Antwortet sie nicht innerhalb von wenigen Sekunden, läuft ein Alarm.

Wichtig dabei: das Monitoring muss von außen kommen, nicht vom gleichen Server, auf dem die Site liegt. Sonst meldet das Werkzeug genau dann nicht, wenn der Server ausfällt — was den Sinn umkehrt.

Was genau geprüft werden sollte:

• Startseite,
• Drei bis fünf wichtigste Unter-Seiten (Produkt-/Service-Übersichten, Kontakt, häufig besuchte Inhalte),
• Die Login-Seite (falls vorhanden),
• Bei Shop: die Warenkorb- und Checkout-Seite.

2. Ladezeit (Performance)

Eine Site, die normalerweise in 1,2 Sekunden lädt und plötzlich 4 Sekunden braucht, signalisiert ein Problem — auch wenn sie technisch erreichbar bleibt. Ursachen sind oft Last-Spitzen, sich aufstauende Datenbank-Anfragen, ausgehende Anbindungen, die langsam antworten.

Empfohlene Mess-Werte:

• Vollständige Ladezeit der Startseite (sollte unter 2 Sekunden bleiben),
• Largest Contentful Paint, also der Zeitpunkt, bis das wichtigste Element sichtbar wird (sollte unter 2,5 Sekunden bleiben),
• Time To First Byte, also die reine Server-Antwort-Zeit (sollte unter 800 Millisekunden bleiben).

Alarm-Schwelle: nicht beim ersten Ausreißer, sondern wenn der gleitende Schnitt der letzten zehn Messungen die Schwelle reißt. Sonst flutet jedes Mess-Werkzeug die Inbox mit Falsch-Alarmen.

3. Formular-Übermittlung (Funktion)

Der wichtigste, am häufigsten übersehene Punkt. Wenn das Kontaktformular eine Bestätigung anzeigt, aber die Mail nicht beim Empfänger ankommt, ist die Site funktional kaputt — auch wenn das Verfügbarkeits-Monitoring grün leuchtet.

Praxis: Einmal täglich (oder bei kritischen Sites einmal stündlich) sendet ein automatisierter Test eine Testmail über das Kontaktformular. Eine zweite Logik prüft, ob die Testmail im Empfangs-Postfach ankommt. Geht die Übermittlungs-Schleife schief, läuft Alarm.

Was zusätzlich geprüft werden sollte:

• Termin-Buchungs-Funktion (Test-Termin wird angelegt und wieder gelöscht),
• Newsletter-Anmeldung (Test-Adresse wird angemeldet und wieder gelöscht),
• Bei Shop: Test-Bestellung mit Test-Zahlungs-Mittel.

4. Zertifikats-Ablauf

Das Sicherheits-Zertifikat einer Site läuft regelmäßig ab. Wenn niemand rechtzeitig erneuert, zeigt der Browser eine Warnung — und Besucher klicken weg. Das passiert im Mittelstand erstaunlich oft, weil das Zertifikats-Datum in keinem Kalender steht.

Monitoring sollte mindestens 30 Tage vor Ablauf warnen, idealerweise 60 Tage. Bei automatischer Erneuerung sollte auch der Erfolg der Erneuerung überwacht werden — manchmal scheitert die Automatik still und das Zertifikat läuft trotzdem ab.

Was zusätzlich überwacht werden sollte (Stufe 2)

Wer die vier zentralen Felder hat, kann eine zweite Stufe ergänzen — Sinn macht das, sobald die Site geschäfts-kritisch ist:

• Server-Last: CPU, Speicher, Festplatten-Belegung. Wer rechtzeitig sieht, dass die Festplatte zu 85 Prozent voll ist, vermeidet den Ausfall bei 100 Prozent.
• Datenbank-Antwortzeit: Eine langsame Datenbank ist meist die Vorstufe eines Ausfalls.
• Anmelde-Versuche (Sicherheit): Auffällige Häufung fehlgeschlagener Anmeldungen ist meist ein Brute-Force-Versuch — Frühwarnung möglich.
• Anzahl 404-Fehler: Wenn plötzlich viele „Seite nicht gefunden“-Fehler kommen, ist meist intern etwas zerbrochen (z.B. nach einem Update).
• Mail-Versand-Erfolg: Ausgehende Mails (Bestätigungen, Benachrichtigungen) werden überwacht — wenn sie sich stauen, gibt es ein Versand-Problem.

Was Monitoring nicht braucht (im Mittelstand)

Drei Werkzeug-Kategorien, die in Konzern-Marketing oft empfohlen werden und im Mittelstand fast immer Überfracht sind:

• Echtes Nutzer-Monitoring mit Heatmaps und Maus-Aufzeichnungen: Datenschutz-rechtlich heikel, Mehrwert für Mittelstand selten gegeben. Wer nicht regelmäßig A/B-Tests fährt, wird die Daten nie auswerten.
• Komplettes Anwendungs-Performance-Monitoring mit Tausenden Kennzahlen: Kostet im Mittelstand vier-stellige Beträge pro Monat und liefert Daten, die niemand interpretiert. Für Mittelstands-Sites Overkill.
• Externe Marketing-Analyse mit personalisierten Profilen: Datenschutz-rechtlich schwierig, geschäftlich für Mittelstand selten relevant. Server-seitige, anonymisierte Auswertung reicht meistens.

Alarm-Disziplin: das wichtigste Detail

Ein Monitoring-System mit zu vielen Alarmen ist schlechter als gar kein Monitoring. Wer jeden Tag fünf Falsch-Alarme bekommt, klickt sie nach drei Wochen ungelesen weg — und übersieht dann den echten Alarm.

Drei Regeln für gute Alarm-Disziplin:

1. Alarm-Schwellen mit Hysterese. Ein Alarm löst nicht beim ersten Ausreißer aus, sondern nach mehreren Messungen in Folge. Damit verschwinden 80 Prozent der Falsch-Alarme.
2. Alarme nach Schwere staffeln. Eine Site, die komplett weg ist, ist ein Alarm der höchsten Stufe (Bereitschafts-Telefon klingelt). Eine Site, die etwas langsam ist, ist ein Alarm der mittleren Stufe (Mail, kein Anruf). Eine Site, deren Festplatte zu 70 Prozent voll ist, ist ein Hinweis (Tages-Bericht, kein Sofort-Alarm).
3. Alarme an jemanden, der reagieren kann. Ein Alarm an eine Adresse, die niemand liest, ist kein Alarm. Bereitschafts-Adressen müssen aktiv betreut werden, Vertretungs-Regelungen müssen klar sein.

Monatlicher Monitoring-Bericht

Einmal im Monat sollte aus den gesammelten Monitoring-Daten ein kurzer Bericht entstehen — keine 30 Seiten, sondern eine halbe Seite mit den vier wichtigsten Werten:

• Gesamt-Verfügbarkeit im Monat (in Prozent, mit Nennung der größten Ausfälle),
• Durchschnittliche Ladezeit der Startseite (mit Entwicklungs-Linie),
• Anzahl der Formular-Übermittlungs-Tests, davon erfolgreich,
• Anzahl der Sicherheits-Auffälligkeiten, davon kritisch.

Ein solcher Monats-Bericht braucht 15 Minuten zum Lesen und gibt dem Inhaber ein realistisches Bild des Gesundheitszustands der eigenen Site. Wer das nicht hat, weiß im Zweifel gar nicht, wie es um die eigene Plattform steht.

Was Hannes daraus macht

Monitoring ist Bestandteil jeder Wartungs-Pauschale, nicht separater Verkaufs-Posten. Die vier zentralen Felder werden automatisch überwacht, kritische Alarme gehen an die Bereitschafts-Stelle, Inhalts-Alarme gehen an den Wartungs-Verantwortlichen. Monats-Bericht kommt automatisch in den Projekt-Übergabe-Ordner. Die Alarm-Schwellen werden in den ersten zwei Monaten nach Go-Live justiert, damit das System ruhig läuft und ernste Vorfälle nicht im Falsch-Alarm-Rauschen untergehen. Wenn du heute auf einer Site sitzt und nicht sagen kannst, wann der letzte Verfügbarkeits-Alarm ausgelöst hat und wer ihn bekommen hat, lohnt sich ein Audit — wir prüfen den Stand und sagen ehrlich, ob die Monitoring-Architektur trägt.