On-Call und Eskalation für dein Team. Geweckt wird nur, wer dran ist.
Plane Rufbereitschaft, Vertretungen und Eskalationsstufen an einem Ort. Uptimeify alarmiert genau die Person, die gerade Bereitschaft hat, und eskaliert automatisch weiter, bis jemand bestätigt.
Entwickelt und gehostet in der
Europäischen Union
DSGVO-konformes Hosting
in Deutschland
Georedundantes Replikat
in der gesamten EU
Pläne, die sich selbst übergeben.
Du legst einmal fest, wer im Team ist, wann übergeben wird und in welcher Zeitzone der Plan rechnet. Ab dann steht für die nächsten Wochen fest, wer dran ist. Keine Tabelle, die nach dem nächsten Urlaub veraltet ist, kein Gruppenchat mit der Frage, wer heute Nacht das Handy hat.
- Rotation im eigenen Takt: täglich, wöchentlich, zweiwöchentlich, monatlich oder frei bis auf die Minute, damit die Übergabe dann passiert, wenn dein Team ohnehin am Schreibtisch sitzt.
- Geschäftszeiten und Zeitzonen im Plan: Wochenfenster wie werktags 09:00 bis 18:00 und eine eigene Zeitzone pro Plan, damit Büro-Bereitschaft und verteilte Teams keinen zweiten Plan brauchen.
- Kalender für das ganze Team: Wer wann Bereitschaft hat, siehst du mit allen Vertretungen in einer Ansicht, damit Lücken auffallen, bevor ein Alarm hineinfällt.

Ein Plan hat genau eine Rotation. rotationMode steuert die Gruppen: none setzt alle Mitglieder als durchgehende Schicht ein, auto teilt den Pool in Gruppen der Größe autoRotationSize, explicit nimmt deine Gruppen in deiner Reihenfolge. Die Kadenz kommt aus rotationRepeats (daily, weekly, biweekly, monthly, custom), bei custom mit Einheit von Minuten bis Monaten. Die kürzeste Schicht ist eine Minute, Übergaben sind minutengenau.
Jeder Plan trägt eine IANA-Zeitzone wie Europe/Berlin. 09:00 heißt 09:00 Ortszeit, auch über die Zeitumstellung hinweg. Kadenzen unter einem Tag laufen in absoluter Zeit, eine Übergabe wird also weder verdoppelt noch verschluckt. Bis zu 50 Wochenfenster pro Plan, ein leeres Feld heißt 24/7. Schichten werden bis zu 90 Tage im Voraus berechnet. Wer gerade dran ist, ist beim Paging damit ein Zeitstempel-Lookup statt einer Live-Rechnung. GET /api/im/on-call und GET /api/im/teams/:id/on-call-now lesen dieselbe Schichttabelle und liefern dasselbe Ergebnis, Vertretungen eingerechnet.
Keine Reaktion? Dann ist die nächste Stufe dran.
Eine Eskalationskette ist die ehrliche Antwort auf die Frage, was passiert, wenn die erste Person nicht abhebt. Du legst Stufen fest, hängst an jede Stufe einen oder mehrere Pläne und bestimmst, nach wie vielen Minuten weitergegeben wird. So bleibt kein Vorfall liegen, nur weil jemand gerade im Funkloch sitzt.
- Gestufte Eskalation mit eigener Wartezeit: Ohne Bestätigung ruft Uptimeify nach der eingestellten Zeit die nächste Stufe, damit dein Reaktionsversprechen nicht an einer einzigen Person hängt.
- Mehrere Pläne pro Stufe: Hamburg tagsüber, Lissabon abends, beide an derselben Stufe, damit Follow-the-Sun ohne Sonderlogik funktioniert.
- Probelauf statt Testnacht: Spiel die Kette für einen Schweregrad und einen Zeitpunkt durch und sieh, wer wann über welchen Kanal erreicht würde, ohne dass ein Telefon klingelt. Warnungen zeigen fehlende Rufnummern, Geräte oder ein leeres Kontingent, bevor es nachts darauf ankommt.

Jede Stufe hat autoEscalationEnabled (Standard an) und autoEscalationAfterMinutes (Standard 5). autoEscalationStopMode entscheidet, ob ein Acknowledge die Kette stoppt (acknowledged, Standard) oder erst die Lösung (resolved). Mit autoEscalationTimeFilters begrenzt du die automatische Eskalation auf Wochenfenster, etwa nur nach Feierabend.
repeats wiederholt das Paging einer Stufe, auf Teamebene wiederholt escalationRepeats die ganze Kette. Das On-Call-Set einer Stufe ist die Vereinigung aller ihrer Pläne. Legst du eine Stufe direkt mit Personen an, entsteht dafür ein 24/7-Plan. Ist keine Stufe mehr übrig, wird der Fallback-Kanal der Organisation gerufen. Aus einem laufenden Vorfall heraus springt „Jetzt eskalieren" sofort zur nächsten Stufe.
POST /api/im/teams/:id/escalation-dry-run geht die Stufen so durch, wie es die Eskalation für einen Vorfall mit severity zum Zeitpunkt at täte, und liefert pro Stufe Person, Kanal, Verzögerung und Warnungen. Es wird nichts gesendet, nichts gespeichert, kein Vorfall angelegt, und Round Robin rückt nicht weiter. Aufrufen dürfen Organisations-Admins, Editoren und Team-Admins.
Urlaub, Krankheit, Schichttausch. Der Plan bleibt, wie er ist.
Abwesenheiten trägst du als Vertretung ein: ein Zeitfenster, in dem jemand anderes übernimmt. Die Rotation rührst du dafür nicht an. Nach dem Urlaub läuft sie weiter, als wäre nichts gewesen, und niemand muss sich merken, wer mit wem getauscht hat.
- Vertretung statt Planumbau: Ein Override setzt jemanden für ein Fenster auf Bereitschaft oder nimmt ihn heraus, damit der Plan nach der Abwesenheit sauber weiterläuft.
- Schicht selbst abgeben: Teammitglieder geben eigene Schichten von bis zu sieben Tagen an eine Kollegin ab, die per E-Mail Bescheid bekommt, damit nicht jeder Tausch über deinen Tisch läuft.
- Für ein Team oder alle Teams: Eine Abwesenheit greift auf Wunsch überall, wo die Person eingeplant ist, damit niemand im Urlaub aus einem zweiten Team heraus geweckt wird.

online setzt eine Person für das Fenster auf Bereitschaft und ersetzt alle anderen, die gerade dran sind. offline nimmt sie heraus, und alle in coveredByUserIds (bis zu 200) bekommen genau die Alarme, die diese Person bekommen hätte. Bei Round Robin ersetzen die Vertretenden die vertretene Person eins zu eins. Gerufen werden alle, auch bei Vorfällen, die schon laufen. Bleibt die Liste leer, entsteht bewusst eine Lücke, die die Eskalation aus einer anderen Stufe füllt.
applyScope: all_teams lässt den Override in jedem Team der Person greifen, escalationTierOrder begrenzt ihn auf eine Stufe. Ein Prioritätsfeld gibt es nicht: Überlappen sich zwei Overrides, gewinnt der später angelegte. Team-Overrides ohne Plan sind möglich. Self-Service ohne Admin-Rechte ist eng geschnitten: genau eine Vertretung aus demselben Team, höchstens sieben Tage, innerhalb der eigenen Schichten, maximal zehn Abgaben pro Stunde.
Erst Push, dann SMS, dann Anruf. Bestätigt mit der 4.
Du gibst deinem Team eine Standardkette vor, zum Beispiel Push sofort, SMS nach fünf Minuten, Anruf nach zehn. Jede neue Person startet damit und passt sie bei Bedarf selbst an. Klingelt nachts das Telefon, reicht die 4, und das Paging stoppt.
- Regeln nach Dringlichkeit: Hohe und niedrige Dringlichkeit bekommen eigene Ketten aus Push, SMS, Anruf und E-Mail, damit ein Sev1 anders klingelt als ein Sev4.
- Standardkette fürs ganze Team: Neue Teammitglieder starten mit deiner Vorgabe, und im Team siehst du, wer eine bestätigte Nummer und passende Regeln hat, damit niemand am ersten Abend unerreichbar ist.
- Anruf, der sich ankündigt: Er beginnt mit „Uptimeify Alarm", wiederholt die Meldung dreimal und wartet auf die 4. Wird er nicht angenommen, kommt nach einer Minute ein zweiter Versuch, damit ein verpasster Anruf nicht das Ende der Kette ist.

Regeln gelten pro Dringlichkeit (high für sev1 und sev2, low für sev3 und sev4) als „nach delayMinutes über Kanal X", Verzögerung 0 bis 1440 Minuten. severityChannels sperrt Kanäle pro Schweregrad.
GET/PUT /api/im/notification-template legt fest, womit neue Personen starten. Die Vorlage wirkt nicht rückwirkend: Wer schon Einstellungen hat, behält sie. Organisations-Admins und organisationsweite Tokens setzen die Einstellungen einer Person über PUT /api/im/users/{userId}/notification-settings, inklusive Rufnummer. Es gilt der letzte Schreibzugriff, lastAdminChangeAt zeigt, wann ein Admin geändert hat. SMS- und Anrufschritte für eine unbestätigte Nummer werden gespeichert und bleiben inaktiv, bis die Nummer per sechsstelligem Code bestätigt ist. Beim Login weist ein Banner darauf hin.
Er beginnt mit „Uptimeify Alarm", liest Vorfalltext und Aufforderung dreimal vor und wartet danach etwa zehn Sekunden auf die Taste. Die 4 bestätigt den Vorfall, jede andere Taste nicht. Das Telefon klingelt 45 Sekunden. Nicht angenommen, besetzt oder abgelehnt heißt: ein zweiter Anruf nach einer Minute, eine Bestätigung in der Zwischenzeit bricht ihn ab. Fällt der Hauptanbieter aus, übernimmt ein zweiter Anbieter mit demselben Text, der die Taste aber nicht erfasst. Dann bestätigst du über den Link in SMS, E-Mail oder Push. Der Testalarm prüft auch den Anruf: Drückst du die 4, bestätigt die Ansage, dass die Taste ankommt.
SMS und Anrufe ziehen aus dem monatlichen SMS-Kontingent, ein Anruf zählt als eine Einheit. Overage ist standardmäßig aus, eine monatliche Obergrenze setzen Organisations-Admins selbst. Ist das Kontingent leer, laufen Push und E-Mail weiter und die Eskalation springt sofort zur nächsten Stufe.
Wir überwachen nicht nur. Wir helfen dir beim Verkaufen.
Jedes Uptimeify-Abonnement enthält Zugang zu unserem Success Kit: eine Sammlung erprobter Ressourcen, um dein Monitoring profitabel zu machen.
Service Level Agreement Vorlagen, um professionelle Grenzen mit deinen Kunden zu definieren.
Finde den Sweet Spot für deine Wartungspläne. Berechne Margen basierend auf Prüfintervallen und Supportstunden.
Präsentationen, die nicht-technischen Kunden 24/7-Monitoring erklären. Schließe mehr Wartungsverträge ab.
Nutze automatisierte Berichte, um proaktiv Wert zu kommunizieren, damit Kunden nie fragen, wofür sie bezahlen.
Bereit, Monitoring in ein Profit-Center zu verwandeln?
Sichere dir dein Success Kit und starte noch heute mit der Skalierung.
Häufig gestellte Fragen
Der On-Call-Plan sagt, wer zu welcher Zeit Bereitschaft hat. Die Eskalationsstufe sagt, in welcher Reihenfolge diese Pläne bei einem Vorfall gerufen werden. In Uptimeify hängen Pläne unter Stufen: Reagiert die erste Stufe nicht, ruft die nächste. So trennst du die Frage „wer ist dran" sauber von der Frage „wer springt ein".
Dann eskaliert der Vorfall nach der eingestellten Wartezeit automatisch zur nächsten Stufe, standardmäßig nach fünf Minuten. Ein nicht angenommener Anruf wird vorher einmal wiederholt. Auf Wunsch wiederholt Uptimeify Stufen oder die ganze Kette. Ist keine Stufe mehr übrig, landet der Vorfall im Fallback-Kanal deiner Organisation, damit er nicht unbemerkt liegen bleibt.
Ja. Ein Alarmanruf beginnt mit „Uptimeify Alarm", liest die Meldung dreimal vor und wartet danach auf eine Taste. Drückst du die 4, ist der Vorfall bestätigt und das Paging für alle anderen gestoppt. Nimmst du nicht ab, ruft Uptimeify nach einer Minute ein zweites Mal an. Danach läuft deine Kette wie eingestellt weiter.
Nein. Incident Management ist ohne Aufpreis in deinem Plan enthalten, Teams und Bereitschaftspläne werden nicht pro Person berechnet. Auf dein Kontingent zählen nur SMS und Anrufe, ein Anruf zählt wie eine SMS. Du kannst also das ganze Team einplanen, statt aus Kostengründen nur zwei Personen auf den Pager zu setzen.
Nein. On-Call-Pläne und Eskalationsstufen sind ein internes Werkzeug deines Teams, Kundenzugänge haben auf Incident Management keinen Zugriff. Dein Kunde sieht das Ergebnis: eine schnelle Reaktion und, wenn du willst, deine Status-Seite. So verkaufst du ein verlässliches Reaktionsversprechen, ohne deine Dienstplanung offenzulegen.
Für den technischen Ansprechpartner
Bereit, deine Bereitschaft planbar zu machen?
Leg dein erstes Team an, bau Plan und Eskalationskette und spiel sie im Probelauf durch, bevor die erste Nacht kommt. Dein Team weiß, wer dran ist. Dein Kunde merkt nur, dass jemand reagiert.