Website monitoring, hosted in Germany

How does LIVCK know a website is broken?

From assertions you write. Out of the box there is exactly one: a status code of 400 or above means down. Beyond that you can assert on response time, body text, JSON fields, response headers, redirects followed, response size, protocol version and the final URL — each assertion resolving to either “down” or “degraded”.

In practice that distinction decides more than check frequency does. An application whose database is gone rarely returns an honest error: the reverse proxy serves its own page with status 200, the CDN serves a cached copy from two days ago, the framework catches the exception and renders an empty page. All three are green to a check that only asks whether the server answers.

A single body assertion closes that gap: some text that only appears on the working page — the name of the signed-in user, the heading of the cart, a field in the JSON response. If it is missing, the page is broken, whatever status code it sends.

Two severities instead of one. “Down” means the service is unusable. “Degraded” means it answers, but not correctly — too slowly, through too many redirects, without the expected header. Both trigger, but not identically: a degraded service does not have to call someone at three in the morning.

What if the endpoint needs authentication, custom headers or mTLS?

Then you configure it that way. LIVCK sends any HTTP method, arbitrary custom headers, a request body, and optionally a bearer token, basic auth or an API-key header. For endpoints behind mutual TLS you can store a client certificate, and for internal authorities your own CA bundle.

That last point looks minor and is expensive. A host with an AAAA record whose IPv6 address does not answer counts as reachable to most checking services — they silently fall back to IPv4, just like most browsers do. For the share of visitors on IPv6-only connections the site is dead anyway, and nobody finds out. With dual-stack detection enabled that becomes a visible state instead of a blind spot.

Client certificates are pasted as PEM or uploaded as a .p12 or .pfx file, with an optional passphrase. The private key is stored encrypted and never leaves the server in clear text. Stored certificates are also watched for expiry — the reminder arrives before a check starts reporting a fake outage caused by an expired client certificate.

If you run an internal certificate authority, upload its bundle as a CA. The probe then trusts that issuer without having to disable certificate verification altogether — the difference between “I trust this CA” and “I stopped checking”.

Method and body

GET, POST, PUT, DELETE, PATCH, HEAD or OPTIONS, plus a request body of up to 10,000 characters — enough to issue a real query instead of merely knocking on the door.

Custom headers

As many as you need. Values are stored encrypted and never shown in clear text again: leaving the field empty keeps the value, entering a new one replaces it.

Authentication

Bearer token, basic auth, or an API key in a header of your choosing. Those secrets are encrypted at rest too.

Redirects

Follow or do not follow. Not following checks the first response — the only way to make a redirect itself the thing under test.

Certificate verification

Can be switched off so an endpoint with a self-signed certificate can be monitored without painting the check permanently red.

IP version

auto, IPv4 only, or IPv6 only. “auto” reports up as soon as either family answers.

Smart dual-stack detection

If the host offers both families but only one is reachable, LIVCK reports “degraded” instead of “up”.

How are false alarms prevented?

In four stages: retries at the location, confirmations over time, a majority across locations — and the rule that nothing goes public on its own. Only when all four are satisfied does an incident exist, and even then it starts out internal.

That last stage saves the most trouble and never shows up in feature matrices. A detection system that publishes automatically turns every false alarm into a public outage notice to every subscriber — and that cannot be taken back. In LIVCK, automatic publishing is off by default.

All thresholds are defaults, not laws of nature. They live in a detection policy that can apply to a single service, to every service carrying a given tag, or to the whole organisation. If you monitor something that is supposed to be reachable from one country only, you adjust the majority rule there — without changing anything for the rest.

Retry

A failed check is retried immediately before the result counts at all. Two attempts by default, adjustable per service.

Confirmation

Three consecutive failing results, otherwise no incident. A single blip evaporates.

Majority

More than half of the measuring locations have to see the same thing. A network node in trouble does not create an incident — it creates a conspicuous row in the report.

Recovery

Two confirmations are enough to call it recovered. Flap detection catches services that bounce between up and down every minute instead of alerting each time.

Publication

A detected incident is an internal matter. Whether it appears on the public status page and reaches subscribers is a human decision.

Why was the site slow?

Because LIVCK breaks every request into its phases: DNS resolution, connection, TLS handshake, waiting for the first byte, and transfer. Only that split tells you whether the problem sits in the network, in the certificate, or in the application.

An average of 85 milliseconds is not a diagnosis. The breakdown below is: 45 milliseconds go to the TLS handshake, 24 to waiting for the first byte, 12 to establishing the connection, 3 to DNS and a single one to transfer. The application is not the bottleneck here — more than half the time passes before it is even asked.

When the shape shifts, so does the cause. Growing wait time means the server is thinking too long. A growing DNS share points at the resolver or at short TTLs. A growing connection share suggests packet loss or a worse route. A growing TLS share means something changed about the certificate or its chain. Without that separation all you can say is that it got slower.

The same split exists per location over time. A line drifting away from the others is a path problem; if all of them rise together, it is the application.

What does the report look like after two weeks?

Availability, response time as mean and as 95th and 99th percentile, the ratio of outlier to mean, plus MTTR, MTTA and MTBF, the longest single outage, availability per location, and the distribution of failure causes.

Mean, P95 and P99

The mean hides outliers. Only the 95th and 99th percentile show what the slowest twentieth and the slowest hundredth of requests experienced.

Tail (P99 divided by mean)

A value of 1.7 means the slowest requests take almost twice as long as average. If it rises while the mean stays flat, the application has become uneven — the classic early warning.

MTTR, MTTA, MTBF

Mean time to recovery, to human acknowledgement, and between incidents. The three numbers a review asks for.

Availability per location

A whole column red means a global outage. A single row red means only that location — and then it is usually the path there, not your site.

Failure causes and status codes

Why checks failed, grouped by cause, plus the distribution of every response status code in the period.

What evidence is left after an outage?

The response itself. When a check fails, LIVCK stores the response body and the response headers exactly as the probe saw them at that moment — together with the location, the timestamp and the state change that goes with it.

That is the difference between “the site was down at 3:12” and “at 3:12 the site served a 502 page from the reverse proxy in Warsaw, with a header pointing at the wrong backend pool”. Without that evidence, debugging the next morning starts with an attempt to reproduce a state that is over, and usually ends in a guess.

This evidence is kept for seven days on Solo, thirty on Team and ninety on Business. The Free plan does not store it.

Who gets woken up, and when?

An escalation policy decides that: stages with a delay between them, a target per stage, and an acknowledgement that stops the chain. If nobody responds, it moves on to the next stage until somebody does.

A target can be a person, a team, an on-call rotation or a chat channel. The rotation resolves who is actually on duty at the moment of the alert — an override entered an hour earlier counts.

How someone is reached is up to them: email, SMS, voice call, WhatsApp. Organisation-wide channels exist for Slack, Microsoft Teams, Telegram, Discord and arbitrary webhooks.

And not every service deserves the same noise. Urgency is set per service to always high, always low, or by schedule. A test system nobody cares about at night gets an email instead of a phone call — without having to switch monitoring off for it.

And how does this become a status page?

From the same data. A monitored service can appear as a component on a public status page; detected incidents, planned maintenance and the history of availability and response time show up there as soon as they are released.

This is why monitoring and status page are one tool in LIVCK rather than two. Separating them means maintaining the same fact twice during an incident — once in the monitoring system, once by hand on the status page, under time pressure and usually incompletely.

A custom domain is included in every plan, the free one as well. Subscribers can follow individual components rather than the whole page, and they are only notified once an incident has been published.