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
New York
Monitoring active
Geneva
Monitoring active
Helsinki
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
Detectionthree check intervals
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.

6 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

Heartbeat

Incoming check-in, run duration, exit code, reported measurements

More planned

Additional check types are in development.

Heartbeat

You cannot ping what never answers.

A backup at three in the morning, a cron job, a queue worker: they run behind the firewall, and from the outside nobody can tell whether they ran at all. So we turn it around — they check in with us.

You get a URL. Your job calls it when it finishes. If the call stays away, we raise the alarm — through the same channels and escalation steps as any other outage.

Four signals, one URL

curl .../ping/TOKENFinished

No suffix: the run succeeded.

curl .../ping/TOKEN/startStarted

Marks the beginning. Add a maximum duration and we also alert when a run hangs and never reports back.

curl .../ping/TOKEN/failFailed

Alarm straight away, without waiting for the next deadline.

curl .../ping/TOKEN/$?Exit code

0 is success, anything else is a failure. One suffix after your command, nothing more.

You define what is expected

Fixed interval

Every five minutes, hourly, daily — up to 30 days apart.

Real cron expression

The same line as in your crontab, in your timezone. Daylight saving included.

Grace period

30 seconds to 24 hours of slack before "late" turns into an alarm.

Maximum duration

Pairs with the start signal: a run that begins and never comes back is just as broken as one that never begins. Leave it empty and this check stays off.

Send the numbers along

The job may post JSON: how many records it processed, how large the backup was, how long it took. Up to ten measurements per run, which you can then watch exactly like anything else.

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

Heartbeats count against your plan's service limit — there is no separate pool and no separate cap.

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 Time299 ms
DNS Resolution12 ms
TCP Connect24 ms
TLS Handshake45 ms
Time to First Byte180 ms
Transfer Time38 ms

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.

Free plan free forever · no credit card.