Stasys

Your own servers are no longer reported as attackers, the same alert no longer opens a new incident every day, and security incidents say what happened in plain words.

Changed

• Security incidents are titled for a person. Instead of a code name such as outbound_to_bad_reputation, an incident now reads like web1: Connected to 203.0.113.9:443, an address this fleet has flagged as an attacker. Open incidents with the old wording are renamed.

Fixed

• A machine in your fleet is never scored, flagged or alerted on as an attacker. A server whose normal traffic tripped another server's web firewall, such as a status page sending its metrics, could build up an attacker score. Every server that talked to it then raised a high-severity incident each day. Standby no longer scores the addresses of machines it manages. After the update it clears the scores already standing against them and closes the incidents those scores opened.
• The same alert no longer opens a new incident every day. While an incident about something is still open, a repeat is added to it instead of opening another.
• Allowlisting one of your own servers closes the alerts about it. For a server of yours that is not enrolled in Standby, allowlisting its address now also closes the open "connected to an attacker" incidents about it.

The console no longer throws away a page that was loading fine.

Fixed

• "This page could not finish loading" no longer appears while nothing is wrong. If one part of the app dropped on its way to the browser, the console reloaded the whole page at once, before the browser's own retry could fetch it. A few of those in a minute ended on the error page. Now the console asks the server first, and reloads only when that part really is gone because Standby was updated while the tab was open.
• The error page is readable in the light theme. When the console does need to show it, the message is no longer pale grey text on a white page.

Meeting links booked from your billing portal no longer carry the product name.

Changed

• Client demo and partner call rooms booked from your billing portal no longer start with "standby-". The join link your customer receives is named after the meeting's subject, for example …/acme-corp-demo-3f9c…. Rooms you start from Standby itself (meetings, chat huddles, incident war rooms) keep their names. Links you have already sent keep working.

Why

The link a customer joins should not name the software you run.

Changed

• The host's WAF card lists the connections that are watched, not blocked.

Fixed

• A blocking WAF on the telemetry or status page server no longer cuts off Standby's own traffic. Log and metric shipping to the telemetry server, and probe nodes reporting to the status page server, are now watched but not blocked when a policy blocks there. Standby recognises each server from the addresses it is set up to use, so other web servers keep full protection on the same paths.

Upgrading

If the telemetry or status page server's WAF is in block mode, apply its policy again after updating.

Status page 0.3.66.

Fixed

• A From that is only a name is no longer saved. With From set to just a name, such as "Standby", the mail server accepted the test email and the page said it was sent, but the recipient's mail service dropped it. Settings → Email (SMTP) now saves only an email address (alerts@example.com) or a name with one (Standby alerts@example.com). Anything else is refused, with a message telling you to use the mailbox you log in with. This replaces 0.16.111's handling, which sent a name-only From from the username's address.
• The From field says what to put in it. Under From, both email settings pages tell you to use the mailbox you log in with, and show your username when it is an address. If what you type is not an address, a warning appears before you save.
• The status page's email settings accept a name with the address. A From such as Status status@example.com was refused there. It is now accepted, under the same rule as Standby's own email settings.

Upgrading

If Settings → Email (SMTP) shows a warning under From after the update, change From to the mailbox you log in with and save. A From that is already saved stays as it is until you save the page.

Why

A sender that is only a name can be saved, and the test email then reports success while nothing arrives. Both email settings pages now catch this when you save.

Fixed

• A blocking WAF on the Standby server no longer takes your servers offline. Agent reports contain file paths, and in block mode the firewall refused them, so servers showed as offline and others lost their security events. When a policy blocks on the Standby server, the agent connection is now watched but not blocked. Hits are still logged, the agent connection still refuses any caller without a valid agent identity, and every other path keeps full blocking.

Upgrading

If your Standby server's WAF is in block mode, apply its policy again after updating.

Fixed

• Email that is not set up yet no longer shows a red "Paging is broken" bar. Pages sent before a mail server was configured counted as a broken channel, and the bar stayed until a page email went out. Email that is not set up is now treated like SMS or voice that is not set up. Open alerts of that kind close themselves after the update. The bar still appears when a configured mail server fails to deliver.

Status page 0.3.65.

Fixed

• Email settings now show which mail server is really in use. When Host was empty, Standby used the mail server set at install, but the page showed nothing. It now names that server and says where it comes from. Typing a host replaces it.
• The test email explains certificate errors in plain words. When the mail server answers under a different name, the message tells you which name to put in Host.
• A From address that is only a name still sends. A From such as "Standby" is sent from the username's address, and the page shows how it will be sent.
• Maintenance times on the status page use one format and timezone. The maintenance timeline, monitor charts and maintenance emails to subscribers now use the same timezone and format as the rest of the page.

Adding people to an on-call schedule now puts them on call. There is no separate Generate step to forget.

Fixed

• Adding members to an on-call schedule puts them on call. A rotation used to produce shifts only after someone also pressed Generate. Until then the schedule warned, every hour, that nobody was rostered. A schedule with members that has never been generated now starts its rotation at the next check and is kept topped up. A schedule with no members still reports that nobody is rostered.

Agents still running on an identity from before a rebuild no longer raise WAF alerts.

Fixed

• Refused agents no longer raise a HIGH WAF alert on every call. Standby already refuses agents still running on an identity from before a rebuild, and lists them on Fleet overview with what to do. Their WAF hits on the agent API now stay in the feed as information.

Monitor maps now place every probe, including the status server's own checks, and the target popup shows plain text (status 0.3.64).

Fixed

• The monitor map's target popup no longer shows "
  " as text. It shows the target, plus its IP address only when that differs from the target.
• Probes appear on the monitor map. The status server's own checks and regions such as "eu-helsinki" had no pin. A probe is now placed from the coordinates you gave it, then a known city in its region name, then its address in the IP-location database. For the status server itself, that is its own public address.

The web firewall no longer reports Standby's own server-to-server traffic as attacks.

Fixed

• Standby's own traffic no longer fills the notifications with WAF alerts. Servers shipping logs to the telemetry server, dashboards querying it, and agents reporting to Standby were flagged as attacks, hundreds of times an hour. A WAF hit now stays in the security feed as information, naming the server, when it comes from one of your enrolled servers or from Standby itself and hits one of Standby's own machine endpoints. The same server hitting anything else still alerts, so a compromised server attacking its neighbours is still reported.

The status page now sees each client's real address: probe nodes show their own IP, and the status page's rate limits apply per visitor again (status 0.3.63).

Fixed

• Probe nodes no longer show "last IP 127.0.0.1", and status-page visitors no longer share one rate limit. The status app was set to trust "one proxy hop" in a form its web server ignores, so it saw every request as coming from its own nginx. It now trusts only the local nginx, so it sees each client's real IPv4 or IPv6 address. A visitor still cannot set that address with a header of their own.
• The probe-node form no longer promises an installer that sets up Node.js. It now says the server needs Node.js 22 or newer.

Upgrading

Update the status page server (Status page → Update) to get status 0.3.63.

Setting up a server from Standby no longer raises a security incident about itself, server pages stop showing their own IPv6 as "seen from", and status-page probes install again (status 0.3.62).

Fixed

• Setting up a status, telemetry, backup or edge server no longer raises a HIGH "download and run" or "reverse shell" incident. Each installer Standby generates now carries a signed mark, valid for 6 hours. A run that carries it stays in the security feed as information, and nobody is paged. A copied or altered mark does not verify, so it still pages.
• A server's page no longer says "seen from" its own IPv6 address. The note now appears only when the agent connected from an address that is not the server's own, for example through NAT or a proxy.
• Installing a status-page probe works again. After 0.16.104 the probe installer did not match the signed probe release, so status servers refused to hand it out ("503"). Status 0.3.62 returns to the signed installer.

Upgrading

Update the status page server (Status page → Update) to get status 0.3.62. On a probe server without Node.js 22 or newer, install Node.js first.

A status-page probe in another region now installs from the two-line command on a fresh server, and the status page app gets the fixes from the last few releases (status 0.3.61).

Fixed

• The probe installer no longer stops on a fresh server because Node.js is missing. The two lines from Status page → Probe nodes now install Node.js themselves (from NodeSource's signed repository on Debian and Ubuntu, from the distribution on Alpine) and install ping.
• Creating a probe node no longer fails with a bare "invalid_body". The fields are trimmed, the naming rule (letters, digits and dashes) is explained, and if the status page refuses, the reason is shown.
• The status page app receives the recent queue and scheduling fixes. The status app's files changed in the last few releases, but its version number did not, so status servers saw no update. Status 0.3.61 carries them.

Upgrading

Update the status page server (Status page → Update) to get status 0.3.61 and the new probe installer.

Scheduled digests are sent once again after the queue library update.

Fixed

• The morning digest and other scheduled digests could still be sent twice after 0.16.102. A digest's schedule is only rewritten when its time changes, and the cleanup of the old registration ran only on that rewrite. The cleanup now runs on every startup.

Recurring background jobs run once per tick again after the queue library update.

Fixed

• After 0.16.100, every recurring background job ran twice each time it was due. On startup, the earlier update was meant to remove the old registration of each job before creating the new one. It missed the format the previous queue library had stored them in, and the new library treated each old registration as a second schedule. This release removes them on startup. Any job that sends something, such as a digest, may have sent it twice in the meantime.

Upgrading

If you installed 0.16.100 or 0.16.101, update to this release. Until you do, every recurring job runs twice each time it is due.

A new install no longer opens incidents about its own empty on-call rota, and old agents calling with a refused identity are named by their server's IPv4 address.

Fixed

• A fresh install no longer opens HIGH "nobody is on call" incidents for its starter schedules. New installs come with three empty starter schedules (Primary, Secondary, Manager). Minutes after setup, each one opened a HIGH incident, and a red bar appeared on every page. Now:
  • When exactly one person can be paged and no fallback has been chosen, that person becomes the on-call fallback, so pages reach them.
  • A schedule nobody has staffed yet, whose pages go to the fallback, is treated as setup still to do.
  • A rota that has run out still raises the alarm. So does any schedule with no fallback set, because then pages really do reach no one.
  • A fallback you cleared on purpose stays cleared.
• Old agents calling with a refused identity are named by server. Fleet overview listed these agents only by the IPv6 address they connected from. It now shows the IPv4 address and hostname each agent reports for itself, with the connecting address underneath.

Upgrading

If your install is showing "Nobody is on call" incidents for the starter schedules, they resolve on the first hourly check after the update.

The background-job queue library moves to its current major version, so the install log no longer warns about a deprecated package.

Changed

• The background-job queue library moves to its current major version. The previous version depended on a package its authors no longer maintain, and every install printed a deprecation warning for it. Recurring jobs moved to the new scheduler in 0.16.99. A server that updates straight to this release clears the old registrations on startup.
• Queue counts on System status no longer include "paused". The new library counts jobs in a paused queue as waiting, so the paused count would always have read 0.

Recurring background jobs move to the job scheduler, ahead of a queue library update. The installer stops printing npm's upgrade notice.

Changed

• Every recurring background job now registers through the job scheduler. Escalations, digests, compliance scoring, retention, backups and fleet checks (38 jobs) now use the job scheduler. The next release updates the queue library, and its new version silently ignores the old way of registering a recurring job: each job would run once and never again. On startup, this release removes the old registrations and creates the new ones. The jobs run at the same times as before.
• The installer no longer prints npm's "new major version of npm available" notice. npm comes with the server's Node.js, so the notice didn't mean anything in your install was out of date.

Fixed

• A server stays online while its agent runs a long job. The agent ran every command in its main loop, so a long job such as a 20-minute recovery drill stopped it checking in. The server looked offline, on-call was paged, and no other command could reach it. Agent 0.160.0 runs long jobs (scripts, backups, restores, package upgrades, malware scans, installs) on a separate worker and keeps checking in and answering meanwhile. Long jobs still run one at a time, and an agent update that arrives during one waits until it finishes.

Upgrading

Update the agents (Fleet → Update all agents) to get agent 0.160.0.

Fixed

• Servers just added to a backup policy no longer page "No successful backup" before their first run. A newly covered server now waits one full schedule window (plus two hours) after the policy changed. If it still has no backup after that, it pages as before.

Fixed

• Web firewall blocks no longer trigger "Service error storm" incidents. The web server logs every firewall decision at error level, so a burst of blocked attacks looked like a failing service. These lines are already recorded as security events and no longer count toward log-rule error counts.

Fixed

• A server running a long job (a recovery drill, a large backup or restore) is no longer reported offline. The agent doesn't check in while it runs a command, so a 20-minute recovery drill made the server look offline and paged on-call. The job was also marked as crashed at a 10-minute default, although it had 30 minutes. Commands now never expire before their own time limit, busy servers count as busy, and a late real result replaces the "crashed" guess.

Fixed

• The security score no longer says the web firewall only detects on sites where it blocks. The condition counts serious attacks that got through the web firewall. On a blocking site these are requests that scored under the blocking threshold, and the wording now says so. The score itself is unchanged.