5 Uptime-Monitoring-Fehler, die Schweizer KMU immer wieder machen (und wie man sie behebt)
Die meisten Schweizer KMU merken erst von einem Kunden, dass die Website down ist oder das Backup nicht lief. Hier sind die fünf häufigsten Uptime-Fehler – und wie Sie diese vermeiden.
Bei einem Schweizer KMU ist eine ausgefallene Website oder ein lautlos fehlgeschlagener Backup-Job selten spektakulär. Es gibt keinen Alarm, kein rotes Licht auf einem Dashboard – nur einen Kunden, der nicht zur Kasse kommt, oder einen Report, der über Nacht einfach nicht generiert wird. Bis es jemand merkt, ist der Schaden bereits da: verlorene Bestellungen, ein frustrierter Kunde oder die hektische Suche nach Daten, die längst gesichert sein sollten.
Das meiste davon liesse sich vermeiden. Das Problem ist nicht Pech – es sind ein paar vorhersehbare Fehler, die so gut wie jedes wachsende Unternehmen irgendwann macht. Hier sind sie, und wie man sie behebt.
Fehler 1: Vom Kunden erfahren statt vom Monitor
Am häufigsten erfahren KMU von einem Ausfall ihres Shops oder Portals durch einen Anruf oder eine wütende E-Mail. Niemand überwacht aktiv die relevanten Endpunkte, sodass das erste Signal von einem Menschen kommt – was bedeutet, dass der Ausfall bereits seit Minuten oder Stunden läuft.
Das passiert, weil ein ordentliches Monitoring-Setup oft als "Das machen wir irgendwann" abgetan wird – etwas für grössere Firmen mit eigener IT-Abteilung. Dabei kostet ein HTTP-Monitor, der Ihre Website alle 30 Sekunden von EU-Infrastruktur aus prüft, nach der Einrichtung praktisch keinen Aufwand mehr – und macht aus jedem Ausfall ein dokumentiertes, mit Zeitstempel versehenes Ereignis statt eines Ratespiels.
Fehler 2: Geplante Jobs nach dem Motto "einrichten und vergessen"
Nächtliche Backups, Rechnungsexporte, Lohnabgleiche, Datenabgleiche – diese Cronjobs laufen still im Hintergrund, und man geht davon aus, dass sie weiterhin funktionieren, weil sie letzten Monat funktioniert haben. Dann wird ein Server umkonfiguriert, ein Credential läuft ab, oder eine Abhängigkeit bricht – und der Job läuft einfach nicht mehr. Niemand merkt es, bis das benötigte Backup nicht da ist.
Cronjob-Heartbeats schliessen genau diese Lücke. Der Job sendet bei jedem erfolgreichen Lauf einen Ping an eine private URL; trifft dieser Ping nicht innerhalb des erwarteten Zeitfensters ein, wird automatisch ein Incident eröffnet – ganz ohne manuelle Kontrolle. Der Unterschied: Sie vermuten nicht mehr, dass ein Backup gelaufen ist – Sie wissen es.
Fehler 3: Alarme, die niemand tatsächlich sieht
Manche Unternehmen haben zwar Monitoring, aber der Alarm landet im Postfach einer einzelnen Person, geht unter oder löst um zwei Uhr nachts aus, ohne dass jemand im Bereitschaftsdienst ist. Ein Vorfall, der sechs Stunden lang unbemerkt bleibt, ist faktisch dasselbe wie gar kein Monitoring.
Die Lösung ist eine Alarmierung, die zur tatsächlichen Arbeitsweise Ihres Teams passt: E-Mail plus Team-Chat-Benachrichtigungen bei jeder Statusänderung, mit Kanälen, Bereitschaftsplänen und Eskalationsregeln, damit die richtige Person informiert wird – nicht einfach diejenige, die den Monitor ursprünglich eingerichtet hat.
Fehler 4: Kein Protokoll darüber, was wann passiert ist
Wird ein Ausfall bemerkt und behoben, dokumentieren viele Teams das Ganze nicht und machen einfach weiter. Drei Monate später passiert dasselbe wieder, und niemand erinnert sich mehr, was damals die Ursache war oder wie lange die Behebung dauerte. Fragt ein Kunde "Wie lange waren wir offline?", bekommt er statt einer Antwort nur ein Achselzucken.
Eine Incident-Timeline mit Quittierungs- und Lösungsaktionen, verketteten Kommentaren und Post-Mortem-Notizen macht aus jedem Ausfall institutionelles Wissen. Response-Time-Tracking und regionale Check-Historien helfen zudem, schleichende Verschlechterungen frühzeitig zu erkennen – etwa einen Dienst, der technisch noch "läuft", aber stetig langsamer wird – bevor daraus ein kompletter Ausfall wird.
Fehler 5: Kunden während eines Vorfalls im Dunkeln lassen
Wenn etwas schiefgeht, macht Schweigen alles noch schlimmer. Kunden laden die Seite immer wieder neu, eröffnen Support-Tickets und befürchten das Schlimmste, weil es keine Möglichkeit gibt, den aktuellen Status nachzuschauen. Ihr Support-Team beantwortet derweil dieselbe Frage "Ist es down?" ein Dutzend Mal.
Eine öffentliche, gebrandete Status-Seite auf Ihrer eigenen Subdomain löst dieses Problem direkt – Sie bestimmen genau, welche Komponenten sichtbar sind, und Kunden können die Antwort selbst finden, statt anzurufen. Das signalisiert zudem Professionalität: Ein Unternehmen, das transparent mit Vorfällen umgeht, wirkt vertrauenswürdiger als eines, das so tut, als gäbe es nie Probleme.
Ein oft übersehenes Risiko: vergessene SSL-Zertifikate
Ein sechster, leiserer Fehler verdient Erwähnung: ein unbemerkt ablaufendes SSL-Zertifikat. Browser zeigen Sicherheitswarnungen an, Checkout-Seiten brechen ab, und das Vertrauen verfliegt innert Sekunden – nur weil eine Zertifikatserneuerung verpasst wurde. SSL-Ablauf-Tracking neben Ihren Uptime-Monitoren schliesst diese Lücke vollständig.
Alles zusammengefasst
All diese Fehler haben denselben Ursprung: Man verlässt sich darauf, dass Menschen Probleme bemerken, die eigentlich Software überwachen sollte. Flitz' Uptime-Monitoring und Status-Seiten decken HTTP/HTTPS-Checks alle 30 Sekunden, Cronjob-Heartbeats, Incident-Timelines, E-Mail- und Chat-Alarme sowie gebrandete öffentliche Status-Seiten ab – alles mandantengetrennt, sodass Ihre Monitore und Vorfälle nie mit den Daten anderer vermischt werden.
Statt separater Tools wie Better Uptime, UptimeRobot, Pingdom oder Atlassian Statuspage ist dies ein Modul innerhalb derselben Plattform, auf der Sie bereits Ihre Rechnungsstellung, Ihr Banking und Ihr CRM verwalten – ein Login weniger, eine Rechnung weniger, und eine Sorge weniger, die sich lautlos einschleichen könnte.