Standby

The result of a maintenance window now reads as one sentence, in the result email and for a paired hosting platform.

Added

• A paired hosting platform shows how each server update it asked for went. Once a window ends, the platform shows the result beside it, for example "3 of 3 servers updated, 41 packages, rebooted 1" or which server failed and why, along with each server's own result. For its own platform updates it shows what it reported itself.

Changed

• The maintenance result email leads with the same one-sentence summary. It says how many servers were updated, how many packages were installed and how many servers rebooted, and names any server that failed, with the reason.

Upgrading

Nothing to do.

Why

Whoever pressed Update now sees what happened without opening the maintenance page.

A paired hosting platform's operator can now update its servers' operating-system packages through Standby with Update now or Schedule, exactly as they update the platform itself.

Added

• A paired hosting platform can update its servers' operating-system packages through Standby, now or at a chosen time. The platform's operator presses Update now, or picks a time, for one server or all of them. Standby carries it out as it does your own maintenance: it installs everything pending, a few minutes apart per server, reboots only when an update needs it, tracks each server's outcome and emails the result. The platform still never runs package updates on those servers itself.
• The platform's own update can also run now or at a chosen time. It is still announced on your status page, and Standby never runs anything in it.

Changed

• A window the platform's operator asks for is kept exactly as asked. It starts at the chosen time, or straight away. It is never moved, does not use the server's one window a month, and needs no emergency reason. It is still announced on your status page and recorded as requested by the platform, and the maintenance page marks it "requested". The 72-hour notice, the monthly window and the 14-day security deadline still govern every window Standby books itself.

Upgrading

Nothing to do.

Why

One place to decide when servers are updated, while Standby still does the work, tells your customers and keeps the record.

A paired hosting platform now books its own updates as maintenance windows in Standby, under the same maintenance policy as your own windows, and shows your status page instead of building one.

Added

• A paired hosting platform books its updates as maintenance windows in Standby. When the platform schedules an update, Standby books it under your maintenance policy: customer notice, one window per server a month (an update may share a window already booked for that server when the times overlap), and emergencies only with a written reason. If the policy cannot fit it, the platform is told why and the earliest time it can have. The window is announced on your status page like any other, and subscribers are emailed.
• Standby never runs anything in a platform's window. It opens the window at its start, after checking the notice period again. The platform runs its update inside it and reports how it went, and the status page entry closes when it does. If the platform has not reported back within 4 hours, Standby closes the window as failed and says so.
• The platform shows your maintenance windows and your status page. It reads the maintenance booked on its own servers, so it can tell its customers when their machines will be updated, and the address of your status page, which it shows instead of having its own.
• The platform can hide or show its servers on your public status page. Hosting is not offered publicly yet, so the platform keeps its servers hidden there until it is.

Changed

• Your monthly maintenance never mistakes a platform's update window for a server's own window. Standby still books the server's own updates, at the same time as the platform's window, so the server is disturbed once. The maintenance page marks platform windows and shows how each one ended.

Upgrading

Nothing to do. The pairing picks up its two new permissions by itself within minutes.

Why

Your customers get the same notice for every disturbance to their servers, whoever causes it, and they see one status page.

A paired hosting platform can now keep the off-site copy of its control plane on your Standby backup node with nothing to set up, and Standby now gives the compliance verdicts for that platform from what it measured.

Added

• A paired kstack platform can keep its off-site backup copy on your Standby backup node, with nothing to type. Once the pairing updates its own permissions (it does this by itself within minutes), the platform asks Standby for a place for the copy. Standby sets up a repository on your default backup node for that platform alone: its credential opens only its own repository, nothing can be deleted with it, and your servers' backups and the platform's copy cannot reach each other. Standby checks all of this on the node before handing the credential over, and again every hour.
• Standby now decides the compliance verdicts for a paired kstack platform. The platform sends what it measured: certificates, website isolation, firewalls, mail authentication, DNSSEC, operator two-factor, dependency advisories, and its backup and restore drills. Standby decides what is met, not met, not measured or not applicable. The kstack page shows Standby's verdict for each, with the platform's own measurement beside it, and lists controls that do not apply separately from open ones.

Upgrading

The backup node must allow scripts (Fleet & endpoints → Host access) for Standby to set up a platform's copy. Until it does, the platform is told why and nothing is created. Nothing is pruned from a platform's off-site copy yet: it is encrypted with a key only the platform holds, so it grows by the platform's small daily change until retention is agreed. Unpairing keeps the copy.

Why

A backup kept only on the same provider and network as the machines it protects is lost with them. This puts a second copy on your own backup node, locked to that one platform, and makes Standby, not the platform being judged, the one that decides whether its controls are met.

Standby's web firewall now leaves the machine your kstack control panel runs on alone, and takes off any firewall it had already put there.

Fixed

• Your kstack control panel's machine is recognised as kstack's. Standby already left the web firewall on kstack's servers to kstack, but it did not recognise the machine the kstack panel itself runs on. It now recognises that machine by the address the panel answers on, and no longer changes its web firewall.
• A web firewall Standby already set up there is removed by itself. Within five minutes of the update, Standby removes the web firewall it installed on that machine and reloads the web server. Only what Standby installed is removed; the packages stay.
• Automatic re-applies never write to a hosting platform's machine. Policies that name your servers are re-applied every five minutes; that re-apply now skips machines a hosting platform manages.

Why

With Standby's web firewall blocking on the kstack panel's machine, most of the panel's buttons failed with "An unexpected response was received from the server", and every change made through kstack's API was refused.

Added

• You choose the order of checks within a component. A check's position can now be set. Before, checks were always listed oldest first, so a check you created again dropped to the end.

Changed

• Checks that belong to one service are shown together. When a component on your status page has several checks (for example a website, a customer portal and licensing that make up one app), they now appear together under the component's name instead of as separate rows among your other services.

Fixed

• Response times from the status server itself are no longer inflated. Its web checks sent the request in a way that could wait on the network's acknowledgement timer, adding 10–50 ms of delay that changed from check to check. A service answering in about 2 ms read up to 54 ms from right next door, higher than from a location 20 ms away. Requests are now sent at once.

Fixed

• The status server's own response times are steady. Its checks ran in the same process that builds and serves the status page, so each reading waited behind that work and came out 10–30 ms too high and uneven. Checks now run in a process of their own. If that process stops, checks fall back to the old way rather than being missed.

Changed

• Remote checking locations now report the service's own answer time. Like the status server's own checks since 0.16.135, a remote location reports the time from sending the request to the first byte of the answer, not the whole fresh visit. A port check reports the connection alone. Remote locations pick up the new probe by themselves.

Changed

• A check's response time is now the service's own answer time. It used to be a whole fresh visit: looking up the name, connecting, the secure handshake and the request, which is three trips across the network, so a service answering in 2 ms showed 39 ms next door and 88 ms from further away. It is now the time from sending the request to the first byte of the answer: one trip plus the server's work, comparable to a ping. A fresh visit's full time is still shown in each check's breakdown.
• A port check's time is the connection alone. The name lookup before it is no longer counted.

Changed

• Every check's breakdown is shown on its page. Under each response time you can see where the time went: name lookup, connecting, the secure handshake and the server's answer. Before, this showed only for failed checks.

Fixed

• The status page shows each checking location's own response time. The p50/p95 column gave one figure for all locations together, and with a near and a far location that figure landed on the far one's side: a check answering in about 40 ms from nearby read 84 ms. Each location now has its own line.
• The status server's checks no longer count their own set-up time. Each check prepared the list of trusted certificates from scratch before connecting, and that time was counted as the service's.

Fixed

• A maintenance notice on your status page names the services it affects. A window for your servers said only "Scheduled maintenance", so customers could not tell whether their email or their downloads would stop. Standby now works out which public services those servers run and the notice says, for example, "Affects Downloads and updates, Email", each linked to its check's page. Notices already published pick it up within the hour, without another email to subscribers.

Fixed

• The status server no longer adds noise to its own response-time readings. It started every check at the same moment each minute, so the checks queued behind each other and a 2 ms connection could read as 75 ms. Each check now has its own place in the minute.
• p50/p95 on the status page covers the last 24 hours. It was taken from the newest 48 checks, about 24 minutes, under a "Last 24 hours" column. It is now worked out over the whole day. Hover over it to see each checking location's own figures.
• The latency chart on a check's page draws one line per location. With two locations it drew a single line that zigzagged between them every minute, which looked like wild swings in response time.

Fixed

• A booked maintenance window gives back servers that no longer need it. When you install updates on a server yourself, Standby now takes it out of its upcoming window within the hour. A window left with no server is cancelled, and so is its notice on the status page. A window that only got smaller is corrected there without sending subscribers another email. Before, windows stayed booked, and on the public page, for servers with nothing left to install.
• A cancelled window no longer stays on the status page. When an update was no longer needed by any server, its window was cancelled in Standby but kept showing as scheduled to your customers. It also cancelled the whole monthly window over that one update, even for servers that still needed theirs.

Fixed

• Updating an app no longer raises "keeps failing" incidents for its services. In 0.16.129, a service that reports a failure each time it is stopped for an update was counted as a scheduled job failing, so a day of updates raised an incident per service. Standby now watches only the failures that background job runners report (a billing run, a sync), and the incidents raised for restarted services close on their own.

Added

• A scheduled job that keeps failing now raises an incident. When the same job fails on a server in three or more hours of the last day (a billing run, a sync, a systemd timer), Standby opens one incident that names the job, the server and its last error, and closes it once the job stops failing. Before, a job failing once an hour was far below anything that alerted, so it could fail for days unnoticed. Ignore rules apply, and "Not a problem" silences it as for any alert.

Security

• Explaining one download-and-run no longer quiets every other one. Marking a download-and-run alert "Not a problem" used to quiet every download-and-run by the same account on that server, so an attacker's would have arrived quietly too. Standby now learns where the script was downloaded from, and only a download from that same place is quiet. A program started from a temporary folder has nothing to learn from, so the next one still alerts. The rules list shows "downloaded from …".

Only one Standby update can run at a time, so pressing Install twice can't break an update.

Fixed

• Pressing Install twice can no longer start two updates. Two updates started a second apart could break each other. Standby kept running the old version, but the update failed. Now only one update can run at a time, and a second attempt is refused before it touches anything.

Your public status page now says where each check runs from, as a city and country.

Fixed

• Visitors see where each check ran from, as "City, Country". The status page used to show internal names such as "local", which a visitor anywhere could read as "near me". Each location now shows its real place. Status page 0.3.69.

Your public status page now shows each check by the name you gave it.

Fixed

• Each check on the public status page shows its own name. Several checks on one site (home page, pricing, documentation) used to all read as the same host name. Status page 0.3.68.

A single site or service going down now opens an incident on its own.

Fixed

• A single failing monitor opens an incident. A site or service check that fails for 3 minutes in a row opens a critical incident, and a failing certificate check opens a high one. The incident names the site and what failed, links to the monitor, and resolves itself when the check passes again or the monitor is removed.

Why

Until now the status page only raised an incident when three or more monitors failed together, so one site down, or a page that loads cut off, could go unnoticed.

"Not a problem" now stops an alert from coming back.

Fixed

• Marking an alert's incident "Not a problem" silences that alert until its source reports it cleared. For a drive, that's when the drive is replaced. Only that one alert is silenced: the same drive getting worse, or another drive, still alerts. The bulk "false positive" action in the incident list does the same. Silences are listed on the incident and can be ended there.

Why

Marking a still-firing alert, such as a worn drive, as "Not a problem" closed its incident, but the next check opened a new one, so you were asked about the same thing again and again.

Standby now tells you when an application's dependencies need a security patch, shows which version to move to, and checks more of your applications.

Added

• A "Patches needed" page lists, for every application, each vulnerable dependency and the version that fixes it. Each entry shows the CVEs that version clears, any that have no fix yet, and the command that applies it. The worst applications come first. The same list appears at the top of each application's page.
• You are told when an application gets a new critical or high dependency CVE. You get one notification per application, listing the versions to move to. A critical one can also page through the CVE pager source. Before this, only CVEs on the known-exploited list were announced.
• The morning digest lists applications with open critical or high dependency CVEs until they are fixed.

Changed

• Applications deployed without a lockfile are now checked. Standby reads what is actually installed: copied node_modules trees (such as Next.js standalone builds) and PHP sites that ship Composer's vendor/composer/installed.json.
• The host agent's own components are checked for CVEs on every Linux server.

Upgrading

Host agents update themselves to 0.161.0. Checking applications deployed without a lockfile needs that agent version. The first check after updating sends one summary of the critical and high dependency CVEs already open.

Why

Vulnerable libraries inside your applications were found but rarely announced: only CVEs on the known-exploited list raised anything. Now every new critical or high one reaches you with the fix.

Security release. Update promptly.

Security updates to the third-party components Standby is built on, including Next.js 16.4.3.

Security

• The admin console is built with Next.js 16.4.3. That release fixes two critical remote-code-execution flaws and a denial-of-service flaw in the Next.js server. Standby ships the console as static pages and never runs that server, so installs were not exposed, but security scanners flagged the old version.
• Expired login tokens can no longer be accepted from a cached check. The library that checks login tokens is updated to its fixed version.
• HTML sanitising, caching and address handling are updated. The HTML sanitiser, the HTTP caching helper, the address parser and the web framework are on their fixed versions. The status page gets the same updates.

Why

Recent advisories rated several of these components critical or high. Updating keeps your install clear of them and keeps your own security scans clean.

Enrolling or re-enrolling a server no longer reports the agent installer's own changes as threats.

Fixed

• Installing or re-installing the agent no longer raises high-severity "file changed" incidents. The installer adds the agent's own system user (so /etc/passwd, group and shadow change), installs its services and removes an older agent. On a server that had been enrolled before, the first report listed all of it as suspicious changes. Changes the agent reports in the first 20 minutes after a server enrols are now recorded as part of the installation, and say so.