Verfügbarkeitsrechner · SLA-Arithmetik

Was deine Neunen wirklich erlauben.

Alle sagen 99,9 % zu, bevor irgendwer ausgerechnet hat, was das zulässt: 43 Minuten im Monat. Wähl unten ein Ziel und lies das Budget — und schau dann zu, was dein Check-Intervall davon abzieht, bevor ein Mensch überhaupt informiert ist.

Ausfallbudget
pro Tag
pro Woche
pro 30-Tage-Monat
pro Quartal
pro Jahr
Der Posten, den niemand einrechnet

Auch das Bemerken kostet Budget.

Ein Ausfall ist nicht vorbei, wenn du ihn behebst. Er beginnt, wenn der Dienst kaputtgeht — inklusive des Teils, in dem es noch niemand weiß.

Der schlimmste Fall ist simpel: Der Dienst fällt direkt nach einem erfolgreichen Check aus, du wartest also ein volles Intervall, bis der nächste hinschaut. Unsere Bestätigung legt ein paar Sekunden drauf — der erste Fehlschlag löst sofort zwei parallele Re-Checks aus, statt auf den nächsten geplanten zu warten.

Diese Zeit ist tot: Du kannst sie nicht ins Beheben stecken. Bei fünf Minuten Intervall sind das fünf von 43 Minuten Monatsbudget, bevor jemand nach dem Laptop greift — und gegen ein 99,99-%-Ziel ist ein einziger unbemerkter Ausfall der ganze Monat.

Das ist das ehrliche Argument für ein kurzes Intervall — und der Grund, warum wir Intervalle bepreisen statt sperren: 10 Sekunden gibt es in jedem Plan, und der Zähler sagt dir vor dem Speichern, was das kostet.

Die Referenz

Jedes übliche Ziel, ausgerechnet.

Kalender-Konvention: Ein Monat hat 30 Tage, ein Jahr 365. Die Prozente beziehen sich auf reale Uhrzeit — so zählt ein SLA, sofern nichts anderes drinsteht.

ZielPro TagPro WochePro MonatPro Jahr

Aus derselben Arithmetik erzeugt wie der Rechner oben — die beiden können nicht auseinanderlaufen.

FAQ

SLA-Fragen, schlicht beantwortet

Welches Ziel soll ich zusagen?
Das, dessen Bruch du überlebst. 99,9 % ist die ehrliche Voreinstellung für ein kleines Team: 43 Minuten im Monat fangen ein misslungenes Deploy und einen Neustart ab. 99,99 % sind 4 Minuten 19 Sekunden im Monat — das ist kein Monitoring-Ziel, sondern eine Architektur-Zusage, und sie braucht Redundanz, auf die ohne Menschen umgeschaltet wird. Eine Neun zuzusagen, die du nicht hältst, kostet mehr, als die Neun wert war.
Zählt geplante Wartung mit?
Nur wenn dein SLA das sagt — und die meisten sagen es nicht, sofern du ein Fenster vorher ankündigst. Genau deshalb lohnt sich eine Statusseite mit geplanter Wartung: Ein angekündigtes Fenster ist ausgenommen, ein unangekündigtes ist Ausfall. Wir messen, was tatsächlich passiert ist; welche Minuten du ausnimmst, ist Sache deines Vertrags.
Misst up4 dasselbe, was mein SLA meint?
Fast — und das lohnt sich zu prüfen. Wir erfassen, ob dein Endpunkt von unseren Probes korrekt geantwortet hat, bestätigt durch drei konsistente Beobachtungen, bevor wir „down“ sagen. Ein SLA meint meist „der Dienst war nutzbar“, und das kann abweichen: Eine Seite, die 200 liefert, während der Checkout kaputt ist, ist nach unserer Messung up und für deine Kunden down. Keyword-Checks schließen den größten Teil dieser Lücke.
Und langsam statt down?
Das trennen wir. Eine Antwort, die spät kommt, ist degraded, nicht down: Sie wird erfasst und ist sichtbar, aber niemand wird für einen trägen Server geweckt. Ob degraded-Zeit gegen dein Budget zählt, ist deine Richtlinie — das Reporting kann sie so oder so maskieren.
Kann up4 automatisch gegen ein Ziel berichten?
Ja. In SLA-Richtlinien setzt du das Ziel und die Geschäftszeiten, für die es gilt; der Monatsreport zeigt die erreichte Quote, das verbrauchte Fehlerbudget und jeden Vorfall, der es verbraucht hat — als PDF, das du unbearbeitet weitergeben kannst.
Warum hier ein 30-Tage-Monat?
Weil die Alternative ist, über den Februar zu streiten. Dreißig Tage nutzt auch der Preiszähler, damit Verfügbarkeits- und Kostenzahl über denselben Zeitraum gerechnet sind. Echte Reports laufen über echte Kalenderbereiche.

Kenn die Zahl, bevor du sie zusagst.

3 € Guthaben · keine Karte · 10-Sekunden-Checks in jedem Plan