Skip to content
LIVCK Cloud

Detect outages before your customers notice.

Distributed monitoring locations check your services at short intervals — every 10 seconds when an outage is suspected. Confirmed multiple times before we wake you.

Strategically Distributed Locations

Monitoring locations in Europe and North America show how your services perform everywhere. The probes only run the check — your data is stored 100% in Germany.

Frankfurt
Monitoring active
Cologne
Monitoring active
Nuremberg
Monitoring active
Enge-Sande
Monitoring active
Vienna
Monitoring active
Warsaw
Monitoring active
Ashburn
In preparation
Geneva
Monitoring active

Majority-Based Detection

No single location triggers false alarms.

Multiple probes must confirm an outage before an incident is created. Individual network issues do not cause false alarms.

4/ 5 locations reachable
FrankfurtOK
CologneOK
NurembergOK
ViennaOK
WarsawFail
No alarm – the majority can reach the service
Normal: your check interval
Detectionup to 3 minutes
Rapid: every 10 seconds
Detectionapprox. 30 seconds

Rapid Re-Check

Faster detection when something looks off — on every plan, including Free.

As soon as a probe suspects an outage, LIVCK automatically switches to rapid mode and checks every 10 seconds. This applies to every plan — including the free plan.

5 Check Types

The right check for every protocol.

HTTP/HTTPS

Status code, response body, headers, redirects, TLS

TCP

Port reachability, connection timeout, banner response

DNS

Record resolution, DNS propagation, nameserver check

ICMP

Ping latency, packet loss, round-trip time

SSL/TLS

Certificate expiry, chain validation, protocol version

More planned

Additional check types are in development.

Conditions & rule sets

Not just reachable – actually healthy

Define custom conditions per service and combine them into rule sets.

An HTTP 200 doesn't mean everything works. With conditions you check status code, response time, content, JSON fields, headers and more – and LIVCK only alerts when one of your rules is violated.

GET api.acme.io/health
HTTP
HTTP statusis200
Response timeunder500 ms
Bodycontains"healthy"
JSON .statusis"ok"
All conditions must pass Service healthy

If a condition fails, LIVCK detects the incident instantly.

https://internal-api.acme.corp
mTLS-protected
Client certificate (mTLS)
partner-client.p12
Trust this CA
ACME Internal Root CA
TLS handshake successful

Certificate valid · 247 days left

mTLS & private CAs

Monitor protected and internal endpoints too

Store your own certificates and monitor HTTP and SSL endpoints that other tools simply can't reach.

Some endpoints require a client certificate (mTLS) or use an internal CA. Store both once in the certificate vault and assign them to your HTTP and SSL checks – encrypted at rest, delivered encrypted to the probes and decrypted there only for the moment of the check – never kept in plaintext.

Client certificate (mTLS)
Presented during the TLS handshake – for internal APIs, partner interfaces and admin endpoints.
Trust your own CA
Check servers behind an internal CA without disabling SSL verification. PEM or PKCS#12/PFX.
Expiry alerts
Email at 30, 14, 7 and 1 day before expiry – rotate the certificate before checks start failing.
Learn more

Detailed Metrics

Understand where time is lost.

Total Response Time
DNS Resolution
TLS Handshake
Time to First Byte
Transfer Time

IPv4 & IPv6

Dual-stack monitoring for complete coverage.

Check your services via IPv4 and IPv6. Detect issues affecting only one protocol before your users notice.

api.acme.io
IPv4203.0.113.10
Reachable
IPv62001:db8::10
Timeout
IPv4 is up, IPv6 isn't responding – a dual-stack check catches it instantly.

Missing something?

Need an integration or feature we don't offer yet? Let us know – we're constantly evolving LIVCK.

Get in touch

Be there early.

Public Beta launches Q3 2026. Free plan stays free forever.