Mehrere Websites und Kunden überwachen: Agentur-Setup

Was ändert sich, wenn man nicht eine, sondern 30 Websites überwacht?

Bei einer einzelnen Website genügt ein Alarmkanal und ein Blick aufs Dashboard. Bei 30 Kundenwebsites entstehen neue Fragen: Wer ist für welchen Kunden zuständig? Wie erkennt man bei einem Alarm sofort, welcher Kunde betroffen ist? Wie informiert man Kunden, ohne jede Störung einzeln zu schreiben? Wie weist man monatlich nach, was geleistet wurde? Und wie legt man 120 Monitore an, ohne einen Nachmittag im Formular zu verbringen?

Die Antwort ist in allen Fällen Struktur. Dieser Artikel zeigt ein Setup, das sich bei Agenturen und Freelancern bewährt hat, und rechnet an einem Beispiel durch, welche Tarifgrenzen relevant werden. Die Funktionen für Agenturen sind zusätzlich auf der Seite Agenturen beschrieben.

Wie viele Monitore braucht ein Kunde, und was passt in welchen Tarif?

Definieren Sie einen Standardsatz, den jeder Kunde bekommt, und einen erweiterten Satz für Shops oder Anwendungen. Ein Vorschlag:

Die Grenzen der Tarife (aus der Konfiguration von UPTIMESHIELD, Stand Oktober 2026):

Eine Rechnung vor dem ersten Kunden spart später den Wechsel. Rechnen Sie außerdem mit Wachstum: Wer 40 Prozent mehr Kunden in einem Jahr erwartet, sollte nicht an der Grenze planen.

Wie benennt und gruppiert man Monitore?

Bei einem Alarm um 07:42 Uhr sehen Sie meist nur den Monitornamen im Chat. Er muss ohne Nachschlagen verraten, wer betroffen ist und was geprüft wird. Bewährt hat sich das Schema Kunde – Bereich – Typ:

• Mustermann GmbH – Startseite – HTTP
• Mustermann GmbH – Zertifikat – SSL
• Mustermann GmbH – Shop-Kasse – Keyword
• Mustermann GmbH – Nachtbackup – Heartbeat

Ergänzen Sie Tags für Querschnittsfragen, zum Beispiel wordpress, shop, wartungsvertrag, hoster-a. Damit finden Sie in Sekunden alle Monitore eines Hosters, wenn dort eine Störung auftritt, oder alle Kunden mit Wartungsvertrag. Die Kundengruppe (Pro/Max) bündelt die Monitore eines Kunden für Berichte, API-Abfragen und Statusseiten. Das Dashboard bietet zusätzlich Favoriten, Sammelaktionen (mehrere Monitore gleichzeitig pausieren, Intervall ändern, Tags setzen), eine Befehlspalette zum schnellen Springen und Import/Export, nützlich für das Anlegen vieler Monitore aus einer Tabelle.

Wie informiert man Kunden, ohne sie mit E-Mails zu überfluten?

Kunden wollen wissen, ob ihre Website funktioniert, und bei einer Störung, dass sich jemand kümmert. Beides lässt sich mit einer öffentlichen Statusseite je Kunde lösen. Sie zeigt Gesamtstatus, 30-Tage-Balken, Verfügbarkeit, geplante Wartungen und die Störungshistorie, aber nicht die überwachten URLs. Mit Pro und Max lassen sich Name, Farbe und Logo anpassen; die Seite kann zusätzlich als JSON-Feed abgerufen werden. Standardmäßig ist sie nicht für Suchmaschinen indexiert, sie lässt sich optional indexierbar machen.

Praxisregeln:

• Teilen Sie dem Kunden die Adresse einmal mit, etwa in der Wartungsvereinbarung. Wer sie kennt, muss bei einem Ausfall nicht anrufen.
• Zeigen Sie auf der Seite nur die Monitore, die der Kunde versteht („Website“, „Onlineshop“), nicht Ihre technischen Hilfsmonitore.
• Planen Sie Wartungen als Wartungsfenster ein, damit sie als geplant erscheinen und nicht als Störung zählen. Mehr in Wartungsfenster planen und Statusseite einrichten.

Wie weist man die Leistung nach?

Pro und Max erzeugen Berichte als PDF, CSV und JSON für einen Monitor, eine Gruppe oder den gesamten Arbeitsbereich, für 7, 30 oder 90 Tage, den aktuellen oder den Vormonat. Der PDF-Bericht enthält Kennzahlen, Tagesbalken, Antwortzeit-Diagramm, Störungsliste und einen Hinweis zur Methodik. Zusätzlich lässt sich ein automatischer Monatsbericht per E-Mail mit PDF-Anhang aktivieren oder abschalten.

Für vertragliche Ziele hilft das SLA-Ziel mit Fehlerbudget je Monitor (30 Tage): Sie hinterlegen ein Ziel, zum Beispiel 99,9 Prozent, und sehen, wie viel Budget im laufenden Zeitraum verbraucht ist. 99,9 Prozent entsprechen rechnerisch 43,2 Minuten Ausfall in 30 Tagen. Sind nach zehn Tagen schon 30 Minuten verbraucht, wissen Sie, dass der Monat knapp wird, bevor der Kunde es merkt. Die Grundlagen erklärt SLA, SLO und SLI erklärt; die Rechnung steht in Verfügbarkeit berechnen.

Seien Sie ehrlich zum Kunden über die Aussagekraft: Der Bericht zeigt Stichproben im Prüfintervall. Eine Störung von zwei Minuten zwischen zwei 5-Minuten-Prüfungen bleibt womöglich unsichtbar. Verweisen Sie auf die Messmethodik und nehmen Sie Wartungsfenster nachvollziehbar in den Bericht auf. Zur Gestaltung vertraglicher Zusagen holen Sie rechtlichen Rat ein; dieser Artikel ersetzt ihn nicht.

Wie organisiert man Team, Alarme und Zuständigkeiten?

Mit Pro (3 Mitglieder) und Max (15 Mitglieder) laden Sie Teammitglieder per E-Mail-Link in den gemeinsamen Arbeitsbereich ein. Wichtig ist die Frage, wer bei einem Alarm reagiert, und zwar ohne dass es von einer Person abhängt:

1. Teamkanal: Ein Kanal in Slack, Microsoft Teams oder Discord, in den alle Monitoring-Alarme laufen. Dort sehen alle, wer reagiert („ich schaue nach“).
2. Bereitschaft: Ein persönlicher Push-Kanal (zum Beispiel Telegram) für die Person mit Bereitschaft; wechseln Sie die Zuordnung im Turnus.
3. Zweitweg: E-Mail an eine betreute Adresse als Protokoll.
4. Erinnerungen: Für Kunden mit Geschäftsrelevanz 15 oder 30 Minuten, für unkritische Kunden 3 oder 12 Stunden.
5. Webhook ins Ticketsystem (optional, mit Signatur), damit jede Störung ein Ticket mit Zeitstempel erzeugt.

Details zu Kanälen, Ruhezeiten und Testversand finden Sie in Benachrichtigungen richtig einrichten. Wenn Alarme so laufen, ist die nächste Frage, was im Ernstfall zu tun ist; ein Muster liefert Ausfall-Notfallplan.

Wie automatisiert man das Anlegen per API?

Bei Dutzenden Kunden lohnt die REST-API (Pro und Max). Mit einem Bearer-Token legen Sie Monitore per Skript an und rufen Uptime, Prüfungen und Berichte ab. Ein Beispiel zum Anlegen eines Monitors:

curl -s -X POST https://uptimeshield.de/api/v1/monitors \
  -H "Authorization: Bearer uc_IHR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"http","name":"Mustermann GmbH – Startseite – HTTP","url":"https://www.mustermann.example/","interval":5}'

Monatsbericht je Gruppe als JSON: GET /api/v1/reports?range=prev_month&group_id=…. Das Schreib-Limit der API beträgt derzeit 60 Anfragen pro Stunde, das Lese-Limit 600; ein Onboarding-Skript sollte deshalb in Paketen arbeiten und die Antwort 429 behandeln. Alle Endpunkte stehen in der API-Dokumentation. Der Ablauf für neue Kunden ist dann: Zeile in der Tabelle ergänzen, Skript ausführen, Gruppe und Statusseite prüfen, Kunden die Adresse der Statusseite schicken.

Welche Fehler machen Agenturen beim Monitoring am häufigsten?

• Alarme gehen an eine Privatadresse. Urlaub oder Krankheit, und die Störung bleibt liegen. Gegenmaßnahme: Teamkanal und Vertretung.
• Zugangsdaten in Monitoren. Wer Header mit Tokens in Monitore einträgt, sollte Rechte im Team beschränken. Eigene Header werden verschlüsselt gespeichert; geben Sie nur die Rechte, die nötig sind.
• Keine Absprache über Wartung. Kunde und Agentur wissen nicht, wann ein Fenster gilt, und der Bericht zeigt eine Lücke, die niemand erklären kann. Gegenmaßnahme: Wartungsfenster immer einplanen und dokumentieren.
• Zu kurze Intervalle für alles. 1 Minute für jeden Monitor verbraucht Kontingent, ohne Nutzen. Gegenmaßnahme: Takt nach Kritikalität.
• Versprechen, die das Monitoring nicht belegt. „Wir garantieren 99,99 Prozent“ lässt sich mit Stichproben nicht belegen. Gegenmaßnahme: Zielwerte als Ziel formulieren, nicht als Garantie.
• Kunde ohne Statusseite. Jeder Ausfall erzeugt dann Telefonate. Gegenmaßnahme: Statusseite beim Onboarding standardmäßig anlegen.
• Offboarding vergessen. Monitore ehemaliger Kunden laufen weiter und verbrauchen Kontingent. Gegenmaßnahme: Gruppe pausieren oder löschen, Kanäle prüfen.

Checkliste: Kunden-Onboarding im Monitoring

1. Kundengruppe anlegen, Namensschema anwenden, Tags setzen.
2. Standard- oder erweiterten Monitorsatz anlegen (HTTP/Keyword, SSL, DNS, ggf. Heartbeat).
3. Prüfintervalle nach Kritikalität wählen.
4. Alarmkanäle zuordnen, Testversand auslösen.
5. Statusseite mit Branding anlegen, Kunden die Adresse mitteilen.
6. SLA-Ziel je wichtigem Monitor hinterlegen.
7. Monatsbericht aktivieren, Empfänger festlegen.
8. Wartungsfenster für bekannte Termine eintragen.

Grenzen und Einordnung

Alle Berichte beruhen auf Stichproben im Prüfintervall. Ohne zusätzlich eingerichtete Standorte misst nur der Hauptstandort, und ein regionales Problem kann unentdeckt bleiben. Das Monitoring prüft Erreichbarkeit und definierte Inhalte; es ersetzt weder Sicherheitsprüfung noch Backup-Test noch eine Browser-Messung der Ladezeit. Statusseite und Berichte sind Kommunikationsmittel, keine rechtlich geprüften Nachweise; Vertragsformulierungen und Haftungsfragen klären Sie mit Fachleuten. Auch die Aufbewahrungsdauer ist begrenzt (Solo 30, Pro 180, Max 365 Tage Rohdaten; Tagesstatistik 400 Tage), sichern Sie Berichte, die Sie länger brauchen, als PDF. Mehr zu den Grenzen: Grenzen automatischer Website-Prüfungen.

Wie setzt man das mit UPTIMESHIELD um?

Starten Sie mit dem kostenlosen Solo-Konto, legen Sie Monitore eines Pilotkunden an und prüfen Sie, ob Namensschema und Alarme für Sie funktionieren. Reichen zehn Monitore, Intervall ab 5 Minuten und eine Statusseite nicht mehr, wechseln Sie auf Pro (7,90 € pro Monat oder 79 € für 12 Monate, einmalige Zahlung per PayPal, kein Abo) oder, bei größerem Bestand, auf den Max-Tarif; die Konditionen stehen auf Preise. Die Funktionen im Überblick: Funktionen. Mit Registrierung geht es los.