# Was ist Website-Monitoring? Der Leitfaden für Agenturen und Dienstleister (2026)

> Was Website-Monitoring ist, welche Check-Typen es gibt und warum es für Agenturen und MSPs geschäftskritisch ist. Der Pillar-Guide 2026.

Source: https://uptimeify.io/de/blog/website-monitoring-leitfaden

Website-Monitoring ist die automatische, wiederkehrende Überprüfung, ob eine Website oder ein Dienst erreichbar ist und korrekt antwortet, verbunden mit einer sofortigen Alarmierung, sobald etwas ausfällt. Statt selbst nachzusehen, lässt du ein System rund um die Uhr prüfen: von mehreren Standorten aus, in festen Intervallen, mit einer Meldung an dein Team im Moment des Ausfalls. Für dich als Agentur oder Dienstleister ist das mehr als Technik. Es ist der Unterschied zwischen "Wir haben es sofort gemerkt" und einem Anruf des verärgerten Kunden.

- **Website-Monitoring** prüft automatisch und in festen Abständen, ob eine Seite läuft, und alarmiert dich beim Ausfall, bevor dein Kunde es merkt.
- Es gibt viele Check-Typen: Uptime (HTTP), SSL, Antwortzeit, Keyword und Seitengröße auf Website-Ebene, dazu DNS, Ping, SSH, FTP, SMTP und IMAP/POP auf Server-Ebene sowie Playwright und Heartbeat als synthetische Checks.
- Das Check-Intervall steuert, wie schnell ein Ausfall auffällt. Entscheidend ist aber die Bestätigung aus mehreren Standorten, damit du echte Ausfälle alarmierst und keine Netzwerk-Schluckaufe.
- Für Portfolio-Betreuer ist Monitoring geschäftskritisch: Es schützt deine Marke, senkt Churn und lässt sich als eigene, wiederkehrende Leistung abrechnen.

## Inhalt

- [Was ist Website-Monitoring?](#was-ist-website-monitoring)
- [Wie funktioniert Website-Monitoring technisch?](#wie-funktioniert-website-monitoring-technisch)
- [Welche Arten von Website-Monitoring gibt es?](#welche-arten-von-website-monitoring-gibt-es)
- [Website-Ebene: die klassischen Checks](#website-ebene-die-klassischen-checks)
- [Server- und Dienst-Ebene: unter der Oberfläche](#server-und-dienst-ebene-unter-der-oberflaeche)
- [Synthetisches Monitoring: Flows und Hintergrundjobs](#synthetisches-monitoring-flows-und-hintergrundjobs)
- [Check-Intervalle: wie oft ist oft genug?](#check-intervalle-wie-oft-ist-oft-genug)
- [Warum Fehlalarme das eigentliche Problem sind](#warum-fehlalarme-das-eigentliche-problem-sind)
- [Warum Monitoring für Agenturen und MSPs geschäftskritisch ist](#warum-monitoring-fuer-agenturen-und-msps-geschaeftskritisch-ist)
- [Häufig gestellte Fragen](#haeufig-gestellte-fragen)

## Was ist Website-Monitoring?

Website-Monitoring ist ein System, das eine Website oder Infrastruktur in regelmäßigen Abständen von außen prüft und dich benachrichtigt, wenn ein Check fehlschlägt. Ein "Check" ist eine einzelne Prüfung: Der Monitor ruft die Seite auf, misst die Antwort und vergleicht sie mit dem erwarteten Ergebnis. Antwortet die Seite mit einem Fehler, zu langsam oder gar nicht, gilt der Check als fehlgeschlagen und ein Ausfall wird registriert.

Der Kern ist die Regelmäßigkeit. Ein einmaliger Blick sagt dir nur, dass die Seite genau jetzt läuft. Monitoring sagt dir, dass sie seit Wochen läuft, wann sie zuletzt ausgefallen ist und wie lange. Aus vielen einzelnen Checks entsteht ein durchgehendes Bild der Verfügbarkeit: die Uptime, meist als Prozentwert über einen Zeitraum angegeben.

Wichtig ist die Perspektive. Gutes Monitoring prüft von außen, so wie ein echter Besucher die Seite erlebt, und nicht vom Server selbst. Ein Server kann sich für gesund halten, während die Seite für die halbe Welt nicht erreichbar ist, etwa wegen eines DNS-Problems oder einer Firewall-Regel. Externes Monitoring sieht genau das, was dein Kunde sieht.

Website-Monitoring verwandelt einzelne Momentaufnahmen in ein durchgehendes Bild der Verfügbarkeit, geprüft von außen, so wie deine Kunden die Seite erleben.

## Wie funktioniert Website-Monitoring technisch?

Website-Monitoring funktioniert, indem verteilte Prüfknoten in festen Intervallen eine Anfrage an dein Ziel senden, die Antwort auswerten und das Ergebnis speichern. Weicht die Antwort vom erwarteten Zustand ab, löst das eine Kette aus: Bestätigung, Incident, Alarmierung.

Der Ablauf hat vier Stufen. Zuerst der **Check** selbst: Ein Prüfknoten sendet zum Beispiel eine HTTP-Anfrage und misst Statuscode, Antwortzeit und Inhalt. Dann die **Bestätigung**: Ein einzelner Fehlschlag reicht nicht. Ein zuverlässiges System prüft den Fehler von weiteren Standorten nach, bevor es ihn als echt einstuft. Danach der **Incident**: Ist der Ausfall bestätigt, wird ein Vorfall eröffnet, mit Startzeitpunkt und Ursache. Zuletzt die **Alarmierung**: Der Vorfall wird an die richtigen Kanäle und Personen geroutet, mit Eskalation, falls niemand reagiert.

Bei Uptimeify läuft dieser Ablauf über neun europäische Prüfstandorte: Nürnberg, Falkenstein, Frankfurt, Berlin, Logroño, Paris, Warschau, Mailand und Helsinki. Ein Ausfall wird von mehreren dieser Standorte bestätigt, bevor ein Incident geöffnet wird. So alarmierst du auf reale Ausfälle statt auf einen lokalen Netzwerkschluckauf an einem einzelnen Node.

## Welche Arten von Website-Monitoring gibt es?

Es gibt kein einzelnes "Website-Monitoring". Es gibt eine Familie von Check-Typen, die jeweils eine andere Ausfallursache abdecken. In der Praxis kombinierst du mehrere pro Kunde, weil eine Seite auf viele Arten kaputtgehen kann: Sie kann komplett offline sein, ein abgelaufenes Zertifikat haben, quälend langsam laden oder erreichbar aussehen, während der Warenkorb dahinter nicht mehr funktioniert.

Die Check-Typen lassen sich in drei Gruppen ordnen: Checks auf **Website-Ebene**, Checks auf **Server- und Dienst-Ebene** und **synthetische** Checks. Die folgende Übersicht zeigt, welcher Typ welche Frage beantwortet.

| Check-Typ | Ebene | Beantwortet die Frage |
| --- | --- | --- |
| Uptime (HTTP) | Website | Ist die Seite überhaupt erreichbar? |
| SSL-Zertifikat | Website | Ist das Zertifikat gültig und läuft es bald ab? |
| Antwortzeit | Website | Lädt die Seite schnell genug? |
| Keyword | Website | Ist der erwartete Inhalt tatsächlich da? |
| Seitengröße | Website | Hat sich die Seite unerwartet aufgebläht? |
| HTTPS-Redirect | Website | Leitet HTTP korrekt auf HTTPS um? |
| DNS | Server / Dienst | Löst die Domain auf die richtigen Werte auf? |
| ICMP (Ping) | Server / Dienst | Ist der Host im Netz erreichbar? |
| SSH | Server / Dienst | Ist der administrative Zugang auf Port 22 offen? |
| SMTP | Server / Dienst | Nimmt der Mailserver Verbindungen an? |
| IMAP / POP | Server / Dienst | Ist der Postfach-Abruf verfügbar? |
| FTP | Server / Dienst | Ist der Dateizugang erreichbar? |
| DNSBL | Server / Dienst | Steht die Mail-IP auf einer Blacklist? |
| Domain-Ablauf | Server / Dienst | Läuft die Domain bald ab? |
| Playwright | Synthetisch | Funktioniert ein mehrstufiger Ablauf wie ein Login? |
| Heartbeat | Synthetisch | Läuft der Cronjob oder Hintergrundprozess wie geplant? |

### Website-Ebene: die klassischen Checks

Checks auf Website-Ebene prüfen das, was ein Besucher direkt erlebt: Erreichbarkeit, Sicherheit, Geschwindigkeit und Inhalt. Sie sind der Kern jedes Monitorings und für die meisten Kunden der offensichtlichste Wert.

Der **Uptime-Check** ist der wichtigste Einzel-Check. Er sendet eine HTTP-Anfrage und wertet aus, ob die Seite mit einem gesunden Statuscode antwortet. Er ist die Grundlage für den Verfügbarkeitswert, den du in Reports und auf Status-Seiten zeigst. Der **SSL-Check** überwacht das Zertifikat und warnt rechtzeitig vor Ablauf, bevor Besucher eine abschreckende Sicherheitswarnung sehen. Der **Antwortzeit-Check** misst, wie schnell die Seite reagiert, und macht schleichende Verlangsamung sichtbar, lange bevor sie zum Ausfall wird. **Keyword-** und **Seitengrößen-Checks** gehen tiefer: Sie prüfen, ob der erwartete Text tatsächlich auf der Seite steht und ob die Seite unerwartet gewachsen ist. Eine Seite kann mit Status 200 antworten und trotzdem kaputt sein, etwa wenn statt der Inhalte eine leere Fehlerseite geladen wird.

Alle Website-Checks von Uptime über SSL bis Keyword in einem Setup: So richtest du sie pro Kunde ein.

### Server- und Dienst-Ebene: unter der Oberfläche

Checks auf Server- und Dienst-Ebene prüfen die Infrastruktur, auf der eine Website aufsetzt. Sie fangen Ausfälle ab, die ein reiner HTTP-Check nicht sieht, weil sie eine Ebene tiefer liegen.

Der **DNS-Check** stellt sicher, dass die Domain auf die richtigen Adressen auflöst. Fällt DNS aus oder wird es manipuliert, ist die Seite unerreichbar, obwohl der Server läuft. Der **ICMP-Check** (Ping) prüft, ob ein Host im Netz überhaupt antwortet. Der **SSH-Check** überwacht die administrative Erreichbarkeit auf Port 22, oft ein Frühwarnsignal für einen kränkelnden Server. **SMTP-, IMAP- und POP-Checks** decken den Mailverkehr ab: ob der Mailserver Verbindungen annimmt und Postfächer abrufbar sind. Der **FTP-Check** prüft den Dateizugang. Dazu kommen zwei Wächter mit direktem Geschäftsbezug: **DNSBL-Monitoring** warnt, wenn die Mail-IP eines Kunden auf einer Blacklist landet und E-Mails still im Spam verschwinden, und **Domain-Ablauf-Monitoring** meldet, bevor eine Domain versehentlich ausläuft.

DNS, Ping, SSH, SMTP und mehr: So überwachst du die Infrastruktur hinter der Website.

### Synthetisches Monitoring: Flows und Hintergrundjobs

Synthetisches Monitoring prüft nicht eine einzelne Antwort, sondern einen ganzen Ablauf oder ein regelmäßiges Signal. Es beantwortet Fragen, die ein einfacher Check nicht beantworten kann: Funktioniert der Login? Läuft das nächtliche Backup?

Beim **Playwright-Monitoring** steuert ein echter Browser einen mehrstufigen Ablauf durch: Seite öffnen, Formular ausfüllen, einloggen, in den Warenkorb legen. Bricht ein Schritt ab, weißt du, dass ein kritischer Pfad kaputt ist, auch wenn die Startseite tadellos lädt. **Heartbeat-Monitoring** dreht das Prinzip um: Statt dass ein Prüfknoten deine Seite aufruft, meldet sich dein Cronjob oder Hintergrundprozess selbst in festen Abständen bei Uptimeify. Bleibt das erwartete Signal aus, wird ein Ausfall registriert. So merkst du, wenn das Backup, der Import oder der Rechnungslauf still gescheitert ist, bevor es jemand vermisst.

Kein Check-Typ deckt alles ab. Uptime sagt "die Seite lebt", Playwright sagt "der Checkout funktioniert", Heartbeat sagt "der nächtliche Job lief". Erst die Kombination ergibt echte Absicherung.

## Check-Intervalle: wie oft ist oft genug?

Das Check-Intervall ist der Abstand zwischen zwei Prüfungen desselben Monitors. Es bestimmt, wie schnell ein Ausfall auffällt: Bei einem Fünf-Minuten-Intervall vergehen im ungünstigsten Fall fünf Minuten, bis der erste fehlgeschlagene Check registriert wird.

Kürzer ist nicht automatisch besser. Ein engeres Intervall verkürzt die Zeit bis zur Entdeckung, erzeugt aber mehr Last und, bei einem schlecht gebauten System, mehr Rauschen. Die richtige Wahl hängt von der Kritikalität ab. Ein Onlineshop, ein Buchungssystem oder ein Kunde mit vertraglich zugesichertem Service-Level wird eng geprüft. Ein Marketing-Blog oder eine Kampagnenseite kommt mit einem entspannteren Intervall aus. Die Faustregel: Je teurer eine Minute Ausfall ist, desto enger das Intervall.

Wichtiger als die reine Frequenz ist, was nach einem fehlgeschlagenen Check passiert. Ein enges Intervall ohne Bestätigungslogik macht dein Monitoring nur nervöser, nicht besser. Genau hier trennt sich brauchbares von unbrauchbarem Monitoring.

## Warum Fehlalarme das eigentliche Problem sind

Der häufigste Grund, warum Teams ihr Monitoring irgendwann ignorieren, sind Fehlalarme. Ein Fehlalarm ist ein Alert für einen Ausfall, den es nie gab: ein kurzer Netzwerkschluckauf, eine einzelne langsame Antwort, eine lokale Routing-Störung an einem einzigen Prüfknoten. Häufen sich diese, stumpft dein Team ab und übersieht irgendwann den echten Ausfall zwischen den falschen.

Die Lösung ist Bestätigung aus mehreren Standorten. Bevor ein Incident geöffnet wird, wird der fehlgeschlagene Check von weiteren Nodes nachgeprüft. Erst wenn mehrere denselben Fehler sehen, gilt der Ausfall als echt. Ein Timeout, den nur ein einzelner Standort meldet, während fünf andere die Seite normal erreichen, ist kein Ausfall der Seite, sondern ein Problem auf dem Weg dorthin. Ein solches Signal darf niemanden um drei Uhr nachts wecken.

Genau so arbeitet Uptimeify: Ein Ausfall wird von mehreren der sechs EU-Standorte bestätigt, bevor die Alarmierung startet. Das Ergebnis ist ein Alert, dem dein Team vertraut, statt ihn wegzuklicken.

Bestätigung aus mehreren Standorten, Eskalation und Routing: So bekommst du Alerts, die stimmen.

## Warum Monitoring für Agenturen und MSPs geschäftskritisch ist

Für einen einzelnen Websitebetreiber ist Monitoring nützlich. Für dich als Agentur oder MSP, der ein Portfolio aus zehn, fünfzig oder hundert Kundenseiten betreut, ist es geschäftskritisch. Der Grund ist simpel: Bei einem Ausfall haftet deine Marke, nicht die des Kunden. Der Kunde ruft dich an, nicht seinen Hoster.

Monitoring wirkt für dich auf drei Ebenen. Es schützt deine **Marke**, weil du von einem Ausfall erfährst und ihn behebst, bevor der Kunde ihn überhaupt bemerkt. Es senkt **Churn**, weil ein Kunde, der jeden Monat einen sauberen Verfügbarkeitsreport unter deinem Logo sieht, spürt, dass er betreut wird, und seltener kündigt. Und es schafft **Marge**, weil du Monitoring nicht als Kostenblock schluckst, sondern als eigene, wiederkehrende Leistung abrechnest. Genau hier wird aus einem technischen Werkzeug ein Umsatzbaustein.

Der Sprung vom Gratis-Checker zur Plattform passiert genau an dieser Schwelle. Ein kostenloses Tool prüft eine Seite von einem Standort und schickt eine E-Mail. Sobald du ein Portfolio betreust, brauchst du Mandantenfähigkeit mit sauber getrennten Kundendaten, gebrandete Status-Seiten unter deiner eigenen Domain, automatische PDF-Reports mit deinem Logo und ein Eskalations-Routing, das im Ernstfall den richtigen Menschen weckt. Bei Uptimeify läuft all das in einem Dashboard, gehostet in der EU, mit einer vollständigen REST-API, über die du Kunden, Monitore und Status-Seiten automatisiert anlegst.

Für einen Betreiber ist Monitoring eine Absicherung. Für dich als Portfolio-Betreuer ist es dreierlei zugleich: Markenschutz, Churn-Bremse und abrechenbare Leistung.

Website-Monitoring ist also weit mehr als die Frage "läuft die Seite?". Es ist ein Zusammenspiel vieler Check-Typen, einer verlässlichen Bestätigungslogik und einer Auslieferung, die deine Marke trägt. Wenn du tiefer in einen einzelnen Baustein einsteigen willst, führen dich der [Uptime-Monitoring-Guide](/de/monitoring/website-monitoring/uptime-monitoring), das [SSL-Monitoring](/de/monitoring/website-monitoring/ssl-monitoring), das [DNS-Monitoring](/de/monitoring/domain-monitoring/dns-monitoring), das [SSH-Monitoring](/de/monitoring/server-monitoring/ssh-monitoring), das [SMTP-Monitoring](/de/monitoring/server-monitoring/smtp-monitoring), das [Heartbeat-Monitoring](/de/monitoring/website-monitoring/heartbeat-monitoring) und das [Playwright-Monitoring](/de/monitoring/website-monitoring/playwright-monitoring) jeweils eine Ebene tiefer. Wie du das Ganze als Leistung verpackst, zeigt der Beitrag [Monitoring als eigene Marke verkaufen](/de/blog/monitoring-als-eigene-marke-verkaufen).
