Changelog

At the registry, LIVCK reads the registration, expiry date, registrar and locks of your domains. In the zone of the extension, it checks whether the domain is listed and which name servers it points to. LIVCK neither reads nor stores data about a domain's holder.

You watch the domain behind an HTTP, SSL, TCP, DNS or ICMP check in the new Domain tab with the checkbox Watch this service's domain. It costs nothing and is ticked when the target is a domain name. A domain without a website behind it is a service of the type Domain, which counts like any other service. Domains in the navigation lists all domains of your services. Each has its own page with the registration, the name servers and their DNS provider, a checklist for its protection and the history. The API and MCP offer the same.

Alarms and notices are not active yet. Monitoring runs silently for the next few days. After that, LIVCK raises an alarm when a domain drops out of the zone or gets suspended, and sends notices about expiry, name servers, registrar, transfer lock and DNSSEC. You can already set when you hear from a domain in the Domain tab under Messages. More in the help.

When a link target lacks https://, the builder adds it as soon as you leave the field. An invalid target is named right then, not only on saving. Fields with a limit count the characters. You sort links and blocks by dragging or with the arrow keys. The preview shows the language you are writing in and follows the open block.

Ctrl+S or Cmd+S saves, Discard undoes all changes. If you leave the page with unsaved changes, the console asks first. If LIVCK refuses a save, the page jumps to the first error. With several languages, a text that applies to all languages now shows in every language tab.

With several custom links and a button, the header ran past its edge: the page name disappeared, and on smaller screens the button and the settings did too. Now whatever has no room moves into the menu behind the cog. A header that fits stays as it is.

When pausing, How long? sets when the service starts again by itself: for 30 minutes, 1 hour, 3 hours, until tomorrow or until a time of your choice, at most 90 days. Until I resume is still there. This works straight from the service list as well. The console counts down to the end. Extend and Resume now change a running pause. A note for your team is visible only in the console and never appears on a status page.

You can put an end on a manually set status, too. After that the status page shows the measured status again. If a maintenance is still running then, it shows the maintenance status instead.

If your plan has no room when the pause ends, the service stays paused. The dashboard shows it, and the owner and admins of your organization get an email. Timed pauses and statuses work through the API and MCP as well. When planning a maintenance, you can now give its end as a duration.

Incidents are split into the tabs Open, Resolved, Internal and All, each with a count. You filter by severity, service, tag, status page and time range, by whether an incident was detected automatically or reported by hand, and search the title. Entries are grouped by day. The filters are part of the address, so you can share a filtered list as a link.

Select all results resolves or deletes everything that matches the filter, across pages too, up to 500 incidents at once. When a new incident comes in, the list no longer jumps. A notice at the top shows it instead.

Maintenances are split the same way into Upcoming & running, Past, Cancelled and All, with filters for type, service, tag, status page and time range.

Put your badge together, copy the snippet and paste it into your website. The badge shows the current status and leads to your status page with one click. Free for every public status page.

Open the badge generator

The overview of every status page shows its badge. Customise badge opens the generator.

An internal incident is on no status page, and nobody is notified. A notice at the top of the incident now says so. In the incident list, on the dashboard and on the service page it carries the Internal badge, and the list can be filtered by it.

When creating an incident, Publish now decides whether it appears right away or stays internal for now. Publish puts it on your status pages later. Before that you see where it appears and which message goes to how many subscribers. Whether it goes out at all is your call, through the API and MCP as well. Make internal takes it off every status page at once.

If you mark an incident as resolved only later, enter under Resolved at when it was really over. This works when resolving, in the update form and on the edit page. The downtime of the affected services follows it. AI assistants can set the time through MCP as well.

In Activity you can now pick several people, categories and channels at once. The active filters sit above the list and can be removed one by one. To covers the whole day in your time zone.

An update with the status Resolved closes the incident. In the update form it therefore now needs the Resolve Incidents right, as it already did in the API. Notes on an incident that is already resolved still work without it.

When you make an internal incident public, your subscribers now get the latest message. Until now they got the first one, so for an incident that was already resolved it still said “We are investigating …”. If you publish an incident again, a message that was already sent no longer goes out a second time unless you ask for it.

Visitors now see your status page in their browser's language. If the page does not offer that language, it appears in English if available, otherwise in its default language. Until now, English-speaking visitors to German-only status pages sometimes landed on an English version that does not exist.

Through the Model Context Protocol (MCP), your AI assistant works with LIVCK directly. You write, for example, “Schedule maintenance tonight from 2 to 4 am for every service tagged db and announce it”. The assistant prepares the maintenance and shows you the text, times and recipients.

It opens incidents and writes their updates, schedules maintenance, creates or edits services and looks for the cause of an outage. Depending on the connection's rights and scope, status pages, on-call, SLA, activity and support tickets come on top.

You create the connection under AI & MCP in your organization's settings. For 30 clients, among them Claude Code, Cursor, VS Code, OpenAI Codex, Gemini CLI, OpenCode and Claude Desktop, the console shows you the finished configuration. Reading is included on every plan, the free one too. Writing comes with Solo and up.

Connect an AI assistant

Anything that reaches customers, wakes someone up, silences alerting or deletes something is shown as a preview first: recipients, texts per language, times and what will be lost. It only runs once you confirm. If someone on your team changes the text after your preview, LIVCK does nothing and the assistant has to ask you again.

For clients that do not ask on their own, choose Approve with a click in the browser. The action then waits under Approvals until you approve it.

Each connection gets No access, Read, Write or Delete per area. Three switches decide what reaches the outside: Notify customers, Wake on-call and Silence or change alerting. A connection never has more rights than the person who created it. Its token only works for MCP, not for the API.

New entries in Activity now show how a change was made: in the browser on a desktop or phone, through the API with the token's name, or by an AI assistant with its client's logo, for example “via Claude Code”. With the Channel filter you can show only the changes made by AI assistants.

Every page of a service now has the same header: name, status with how long it has held, check type and target. Edit and Pause sit right next to it, Set status manually, Duplicate and Delete are in the ⋯ menu.

Below it, tabs switch between Overview, Insights, Checks and Artifacts, and for server agents between Overview, Analysis and History. When you jump to another service, you stay on the same tab.

Open services

Above the list you can filter by Status, Type, Provider and Tags. Several values in one filter show every matching service, several filters together only those that match all of them.

Below the uptime there is a strip with one field per day of the last 30 days, so the list shows when there were problems.

The overview shows the response time as a full chart and two new cards.

Performance by location shows uptime and average response time per monitoring location for the last 7 days, the slowest first. Connections shows who gets alerted during an outage, which incidents are open, which maintenances are coming up and on which status pages the service appears.

Uptime and other percentages in the console now follow the format of your language. In German that is “99,55 %”, in English it stays “99.55%”.

Solo now includes three monitoring locations instead of two. With three locations a real majority decides whether a service is down: two of three have to report the failure. If only one location reports a failure, the service counts as degraded, not as down.

Add the third location in your organization's settings or per service.

See plans

When a check failed because one of your conditions matched, Insights showed “No failures” under Failure reasons. Those checks now appear there as a cause of their own.

Next to the grace period a heartbeat now has Confirmations before alerting (1 to 5). At 1 we alert immediately on the first missed interval, exactly as before.

The default is 2 for intervals up to five minutes and 1 above that. The reason: confirmations times interval is your time to alert — on a daily backup two rounds would be two days.

Two cases still alert immediately, whatever you set: a ping to /fail, and a run that started but never reported finishing. Your script reports both itself, so nothing was lost in transit.

We have already set existing heartbeats with a short interval to 2. Their time to alert grows by one interval — if you do not want that, set the value to 1.

Open heartbeats

Until now a single missing ping was enough to flip a heartbeat to Down and notify you. On a job that runs every minute that meant: one request lost in transit becomes an incident — even though your job ran fine.

Now we count. Only when several intervals are missing in a row do we treat the service as down. Every incoming ping resets the counter: one hiccup in the morning and one in the afternoon do not add up.

Recovery stays immediate — the first ping that arrives again puts the service back to Up.

With GET, POST and DELETE /v1/enrollment-keys you manage keys. The key itself only appears in the response when you create it, together with the ready-made install command. Every key lists the server agents that enrolled with it.

Every server agent has the agent block in the API with its state, host data, update settings and the key it enrolled with. GET /v1/services/{id}/agent-metrics returns the current values, /agent-metrics/history the history.

Enrollment tokens now carry real tags of your organization. Server may add its own tags decides whether tags from the install command are added. A token's tag may also fill a status page group.

Open enrollment tokens

When you share an invitation in Slack, Teams or WhatsApp, the preview shows the organization's name and who is inviting.

When measurement data is briefly unavailable, /checks and the server agent metrics answer with empty values instead of an error.

Every webhook now carries the headers webhook-id, webhook-timestamp and webhook-signature. X-Signature-256 stays.

LIVCK now generates the secret and shows it to you once. Webhooks without a secret get one automatically. When you renew it, the old one keeps signing webhook-signature for 24 hours. X-Signature-256 switches right away.

Open integrations

Every delivery shows its event ID and, on failure, the reason, such as timeout or DNS. Retries carry the same ID, so you can spot duplicate deliveries. Webhooks of your subscribers are now retried on failure too.

A webhook now only counts as delivered when your endpoint answers with 2xx. Until now a redirect counted too, although your endpoint never got anything. We no longer follow redirects. If your endpoint redirects, enter the target address directly.

Test now sends a signed sample alert in the real format. Until now it sent an unsigned message that receivers checking the signature rejected.

In the service overview, every target shows the logo of its provider, such as Hetzner, Cloudflare or STACKIT. For server agents it appears next to every IP address. The tooltip shows the name, country, addresses and whether a CDN sits in front.

We detect new and changed services within a few seconds.

Open services