Zum Inhalt springen
LIVCK Cloud

Ausfälle erkennen, bevor deine Kunden sie bemerken.

Verteilte Mess-Standorte prüfen deine Services in kurzen Intervallen — im Verdachtsfall sogar alle 10 Sekunden. Mehrfach bestätigt, bevor wir dich wecken.

Strategisch verteilte Standorte

Mess-Standorte in Europa und Nordamerika zeigen dir, wie deine Services überall erreichbar sind. Die Probes führen nur den Check aus — deine Daten werden zu 100 % in Deutschland gespeichert.

Frankfurt
Monitoring aktiv
Köln
Monitoring aktiv
Nürnberg
Monitoring aktiv
Enge-Sande
Monitoring aktiv
Wien
Monitoring aktiv
Warschau
Monitoring aktiv
New York
Monitoring aktiv
Genf
Monitoring aktiv
Helsinki
Monitoring aktiv

Majority-basierte Erkennung

Kein einzelner Standort löst Fehlalarme aus.

Mehrere Probes müssen einen Ausfall bestätigen, bevor ein Incident erstellt wird. Einzelne Netzwerkprobleme führen nicht zu falschen Alarmen.

4/ 5 Standorte erreichbar
FrankfurtOK
KölnOK
NürnbergOK
WienOK
WarschauFehler
Kein Alarm – die Mehrheit erreicht den Service
Normal: Dein Check-Intervall
Erkennungdrei Check-Intervalle
Rapid: alle 10 Sekunden
Erkennungca. 30 Sekunden

Rapid Re-Check

Schnellere Erkennung im Verdachtsfall — in jedem Plan, auch Free.

Sobald eine Probe einen Ausfall vermutet, wechselt LIVCK automatisch in den Rapid-Modus und prüft alle 10 Sekunden. Das gilt für jeden Plan — auch den kostenlosen Free-Plan.

6 Check-Typen

Für jedes Protokoll der richtige Check.

HTTP/HTTPS

Status-Code, Response-Body, Header, Redirects, TLS

TCP

Port-Erreichbarkeit, Connection-Timeout, Banner-Response

DNS

Record-Auflösung, DNS-Propagation, Nameserver-Prüfung

ICMP

Ping-Latenz, Paketverlust, Round-Trip-Time

SSL/TLS

Zertifikats-Ablauf, Chain-Validierung, Protokoll-Version

Heartbeat

Eingehende Meldung, Laufdauer, Exit-Code, mitgeschickte Messwerte

Weitere in Planung

Zusätzliche Check-Typen sind in Entwicklung.

Heartbeat

Was nicht antwortet, kann man nicht anpingen.

Ein Backup um drei Uhr nachts, ein Cronjob, eine Warteschlange: Sie laufen hinter der Firewall, und von außen sieht niemand, ob sie gelaufen sind. Also drehen wir es um — sie melden sich bei uns.

Du bekommst eine Adresse. Dein Job ruft sie auf, wenn er fertig ist. Bleibt der Anruf aus, schlagen wir Alarm — über dieselben Kanäle und Eskalationsstufen wie bei jedem anderen Ausfall.

Vier Signale, eine Adresse

curl .../ping/TOKENFertig

Ohne Zusatz: der Lauf war erfolgreich.

curl .../ping/TOKEN/startGestartet

Markiert den Beginn. Legst du zusätzlich eine Höchstdauer fest, schlagen wir auch Alarm, wenn der Lauf hängt und nie zurückmeldet.

curl .../ping/TOKEN/failFehlgeschlagen

Sofortiger Alarm, ohne auf die nächste Frist zu warten.

curl .../ping/TOKEN/$?Exit-Code

0 ist Erfolg, alles andere ein Fehler. Ein Anhängsel hinter deinen Befehl, mehr nicht.

Erwartet wird, was du festlegst

Fester Takt

Alle fünf Minuten, stündlich, täglich — bis zu 30 Tage Abstand.

Echter Cron-Ausdruck

Dieselbe Zeile wie in deiner Crontab, mit deiner Zeitzone. Sommerzeit inklusive.

Karenzzeit

30 Sekunden bis 24 Stunden Luft, bevor aus „spät“ ein Alarm wird.

Höchstdauer

Zusammen mit dem Start-Signal: Ein Lauf, der beginnt und nicht zurückkommt, ist genauso kaputt wie einer, der nie beginnt. Ohne Angabe bleibt diese Prüfung aus.

Zahlen gleich mitschicken

Der Job darf JSON mitgeben: wie viele Datensätze verarbeitet wurden, wie groß das Backup war, wie lange es dauerte. Bis zu zehn Messwerte je Lauf, die du anschließend genauso überwachen kannst wie alles andere.

{ "rows": 14203, "size_mb": 812 }

Heartbeats zählen auf die Service-Grenze deines Plans — es gibt keinen eigenen Topf und kein eigenes Limit.

Conditions & Regelsätze

Nicht nur erreichbar – sondern wirklich gesund

Definiere pro Service eigene Bedingungen und kombiniere sie zu Regelsätzen.

Ein HTTP-200 heißt nicht, dass alles läuft. Mit Conditions prüfst du Statuscode, Antwortzeit, Inhalt, JSON-Felder, Header und mehr – und LIVCK schlägt erst Alarm, wenn eine deiner Regeln verletzt wird.

GET api.acme.io/health
HTTP
HTTP-Statusist200
Antwortzeitunter500 ms
Bodyenthält"healthy"
JSON .statusist"ok"
Alle Bedingungen müssen erfüllt sein Service gesund

Schlägt eine Bedingung fehl, erkennt LIVCK den Vorfall sofort.

https://internal-api.acme.corp
mTLS-geschützt
Client-Zertifikat (mTLS)
partner-client.p12
Dieser CA vertrauen
ACME Internal Root CA
TLS-Handshake erfolgreich

Zertifikat gültig · noch 247 Tage

mTLS & private CAs

Auch geschützte und interne Endpunkte überwachen

Hinterlege eigene Zertifikate und überwache HTTP- und SSL-Endpunkte, an die andere Tools nicht herankommen.

Manche Endpunkte verlangen ein Client-Zertifikat (mTLS) oder nutzen eine interne CA. Hinterlege beides einmal im Zertifikats-Tresor und weise es deinen HTTP- und SSL-Checks zu – verschlüsselt gespeichert, verschlüsselt an die Probes ausgeliefert und dort erst im Moment des Checks entschlüsselt – nie dauerhaft im Klartext.

Client-Zertifikat (mTLS)
Wird beim TLS-Handshake vorgezeigt – für interne APIs, Partner-Schnittstellen und Admin-Endpunkte.
Eigener CA vertrauen
Server mit interner CA prüfen, ohne die SSL-Verifizierung auszuschalten. PEM oder PKCS#12/PFX.
Ablauf-Warnungen
E-Mail bei 30, 14, 7 und 1 Tag vor Ablauf – tausche das Zertifikat, bevor Checks fehlschlagen.
Mehr erfahren

Detaillierte Metriken

Verstehe, wo Zeit verloren geht.

Gesamte Response-Zeit299 ms
DNS-Auflösung12 ms
TCP-Verbindung24 ms
TLS-Handshake45 ms
Time to First Byte180 ms
Transfer-Zeit38 ms

IPv4 & IPv6

Dual-Stack-Monitoring für vollständige Abdeckung.

Prüfe deine Services über IPv4 und IPv6. Erkenne Probleme, die nur ein Protokoll betreffen, bevor deine Nutzer sie bemerken.

api.acme.io
IPv4203.0.113.10
Erreichbar
IPv62001:db8::10
Timeout
IPv4 läuft, IPv6 antwortet nicht – mit Dual-Stack-Check fällt das sofort auf.

Dir fehlt etwas?

Du vermisst eine Integration oder Funktion? Lass es uns wissen – wir entwickeln LIVCK ständig weiter.

Kontakt aufnehmen

Sei früh dabei.

Free-Plan dauerhaft kostenlos · keine Kreditkarte.