Standby

SSDs near the end of their rated life now warn, a server model chosen by hand that contradicts the hardware is flagged, and Locate is no longer offered on drives that have no light. Host agent 0.135.0 is included.

Fixed

• An SSD near the end of its rated life warns. The host page's disk list warned at 80 % wear, but the drive report only warned at 90 %, and on a server that reports drive bays the drive report decides — so a drive at 86 % or 89 % raised nothing. Drives now warn at 80 % wear, or when less than 20 % of their spare capacity is left. These warnings page nobody.
• A server model chosen by hand that contradicts the hardware is flagged. If you pick a rack model for a server that reports itself as a desktop or tower, the front panel says that the drawn bays may not exist, and how to go back to Automatic.
• Locate is no longer offered on drives that have no locate light. On an internal drive (in a desktop or tower, an M.2 inside the case, or a VM's virtual disk) it failed with "ledctl is not installed (package: ledmon)", which suggested that installing ledmon would help. It would not. The drive panel now says there is no light to blink.

Upgrading

After updating, open Fleet → Update all agents.

Installing the agent on a physical server now also installs smartmontools, so disk health can be read from the start.

Changed

• Installing the agent on a physical server also installs smartmontools. Disk health can then be read from the start. Virtual machines and containers get nothing extra. On Debian and Ubuntu, no recommended packages (such as a mail server) come with it. If no package repository is reachable, the agent still installs, and the installer says what is missing.

Upgrading

Servers enrolled before this release are not changed. On a physical server that shows "smartctl is not installed", install smartmontools once with its package manager.

Virtual machines no longer get "disk health cannot be read" warnings.

Fixed

• Virtual machines no longer get "disk health cannot be read" warnings. A virtual disk has no health data to read, so the warning that 0.15.3 raised on every virtual machine, and the incident it opened, was noise. It is now raised only for physical servers. The warnings already open on virtual machines close by themselves within half an hour of updating.

A disk whose health cannot be read now says why and raises a warning, desktop and tower servers are drawn as what they are, and the DC Room helps you re-link a racked server whose agent was re-enrolled. Host agent 0.134.0 is included.

Fixed

• A disk whose health cannot be read says why, and raises a warning. On a host without smartctl, no disk health was ever read, so a failing disk could never turn red or page. The host page, the side panel and the DC Room now give the reason, for example "smartctl is not installed on this host — install smartmontools so disk health can be read". A warning is raised once per host; it pages nobody and clears when disk health is read again.
• Desktop and tower servers are drawn without front drive bays. They were drawn as a 1U server with ten front bays. Their drives are now listed as internal, and M.2 drives are recognised from their model number.
• A racked server whose agent was re-enrolled can be re-linked. The DC Room showed it as "no agent linked". It now says the host no longer exists. When a live host has the same name, the right-click menu offers to re-link it; you can also clear the stale link. Either action asks you to confirm first.
• Windows hosts say drive bays are not reported on Windows yet. They were told drive bays arrive with a newer agent.

Upgrading

After updating, open Fleet → Update all agents. If a host then says "smartctl is not installed", install smartmontools on it so its disk health can be read.

Why

An unreadable disk must never look the same as a healthy one: a host without smartctl could not turn a failing disk red or page anyone.

The DC Room up close: inspect a rack's drive bays, see each round's coverage, check a rack's power budget before you move a server, and walk an aisle rack by rack. Host agent 0.133.0 is included.

Added

• You can inspect a rack's drive bays. Double-click a rack or server, or choose "Inspect drive bays" from a server's right-click menu. Every server in the rack is drawn large, and each bay opens its disk's SMART summary. You can blink its locate LED after confirming.
• The Rounds layer shows which racks each DC round covers and when each was last checked. Also shown on the rack: overdue rounds (with a dashed amber outline), open shift-log items pinned to it, and overdue maintenance. A route picker draws one round's walk rack by rack.
• Dragging a server shows the rack's power budget before and after the move. The target rack shows its draw against its rating, per feed. The server's draw is its measured input power, read from its BMC. If there is no reading, the room uses a budget you set on the server (Servers page or the right-click menu); with neither, it says "unknown". Over budget turns the drop zone red, and the confirmation says so.
• Walk the aisle moves the camera rack by rack. Choose "Walk " in the view picker. The camera stays longer on racks with a problem. Space pauses, the arrow keys step, Esc stops. If your system asks for reduced motion, it jumps instead of gliding.
• A server's front panel shows its measured input power. On the host page, with the time it was measured.

Changed

• Incidents in the DC Room sit on the server. An affected server shows a red count, and the incident cards sit beside the room. Lines from a card to its servers appear only while you point at the card.

Upgrading

After updating, open Fleet → Update all agents. A server's measured power draw needs agent 0.133.0 and a BMC that reports it.

Why

The room now answers the questions you have standing in front of a rack: which disk is failing, when this rack was last checked, and whether this server fits on this feed.

Six more maps: your paired systems, DNS replication, backups, the network mesh, attack campaigns and an incident's blast radius. Pages for warning-severity incidents are recorded in the notification log again.

Added

• The platform map shows every system Standby is paired with, and whether each link is healthy. Open it from Integrations → Map. Billing, the release store, the update service, hosting control planes, the CVE data source and the status page each have a line with its health and last sync, flow by flow: red when a flow is failing or stale, with the reason; grey when it is unknown; dashed when the pairing is not set up.
• The DNS topology shows how far each secondary lags behind its primary. Open it from DNS nodes → Topology. Amber means a secondary was behind on the last check; red means behind on two checks in a row (when you are paged), not answering, or missing from the last transfer.
• The backup map shows every host, the store it backs up to, and whether it is on time. Open it from Backups → Map. Each line is coloured against the host's own schedule. Each store shows its capacity and its last restore drill.
• The network mesh shows tunnels and replication across your hosts. Open it from Network → Mesh: hosts and their network cards per datacenter, switch ports, encrypted tunnels to edge nodes with their last handshake, and replication to a standby with its lag.
• Attack campaigns group attacks by source network and kind. Open Threats → Campaigns: attacker addresses, the hosts they targeted and what they tried. Click an address to open its side panel.
• The incident page shows the incident's blast radius. A Blast radius section draws the incident's hosts, everything that depends on them, and the status-page components they feed.

Fixed

• Pages for warning-severity incidents are recorded in the notification log again. The log refused the incident's severity, so those emails, texts, calls and push messages were sent but missing from Notifications → Log. They are recorded again, and older entries are converted on update.
• The overview box in the corner of each map shows the map. It was empty on the CMDB map and others.

Upgrading

The DNS topology map fills in about ten minutes after updating, once the drift check has run.

Why

Each map answers one question at a glance, such as "which secondary is behind?", "which host has not backed up?" or "what does this incident take down?", and a click opens the side panel to act on it.

The DC Room draws your racks and servers on a floor, physical servers show their real front with a light per drive bay, and side panels let you act on hosts, incidents, alerts, people and more without leaving the page. The sidebar is shorter, and new maps show escalation chains, CMDB dependencies and change plans. Host agent 0.132.0 is included.

Added

• Side panels open what you click without leaving the page. Clicking an IP address, a host, an incident, an alert, a person, a change plan, an approval request, a CVE, a package, a change on a host or a Zephyr audit entry almost anywhere opens a panel on the right with what you need to act on it. The page behind it stays where it was. The panel has its own link, so Back or Esc closes it, and Ctrl/Cmd-click still opens the full page. Opening something from inside a panel keeps a short "Back to…" trail.
  • Person: which channels can actually reach them, who is on call now and next, their open incidents and the chains that page them. You can take their on-call shift, or page them through their chain.
  • Alert: labels, firing history, silences and its incident. You can silence it (scoped to its host and metric) or acknowledge its incident.
  • Change plan: steps, dry-run output and status, with submit and cancel.
  • Approval request: what will run, the dry run and what it affects, with approve or deny in place. You can never approve your own request; the panel says why.
  • Host change: before and after, plus any incident on that host in the two hours after the change. Where the change can be undone (a package installed or removed, a service started or stopped), you can file a change plan to revert it.
  • CVE: CVSS, EPSS, KEV, the fixed version and the affected hosts. You can file one change plan that upgrades every affected host, or accept the risk with a reason.
  • Package: every version across the fleet and the hosts on each, with an upgrade plan for the hosts that are behind.
  • Zephyr audit entry: the entries before and after it, with whether each hash link holds, and the actor's other actions. You can raise an incident from it.
• The sidebar is shorter and no longer needs scrolling on a laptop. The menu has 11 groups instead of 16, and each shows at most eight everyday pages; the rest are one click away under "more". Only the group you are in is open, and the scrollbar is thin and shows only while you scroll. You can pin pages to the top. Your personal pages (profile, notifications, downloads) are on your avatar.
  • Ctrl/Cmd+K jumps to any page you are allowed to open.
  • Map of Standby (the compass next to it) draws every area and page, with live counts of open incidents, firing alerts and pending approvals.
• The DC Room draws your datacenter as a floor of racks. Find it in the sidebar under Network & datacenter. Every server sits in its U position with a status light that pulses while an incident is open.
  • Zoom in for names, load and agent version. Turn on layers for network, power, heat, dependencies, incidents and changes.
  • Cloud and VPS hosts that are not in a rack sit in virtual racks.
  • Drag a rack to move it on the floor. Drag a server to a new U position; the move is checked for collisions before you confirm it.
  • Right-click a server to blink its locate LED, file a change plan to restart a service or upgrade packages, or refresh its probes.
  • Select several servers to file one change plan for all of them.
• Physical servers show their real front, with a light per drive bay. Servers are drawn as their actual chassis model, bay by bay: 3.5", 2.5", U.2, E1.S, E3.S or M.2. A failed disk shows red and opens an incident that pages. A disk with warnings opens an incident without paging anyone. A disk that dies and drops off the bus keeps its red light.
  • The front panel appears on the host page, in the host side panel and in the DC Room when you zoom in.
  • Click a bay for that disk's SMART summary, to blink its locate LED, or to set the chassis model.
• The escalation map shows who gets paged, on which channel, and when. Open it with the Map button on each escalation chain.
  • Channels that cannot deliver are red, with the reason: no SMS or voice provider configured, no phone number or push device, a channel the person has switched off, or nobody on call.
  • A slider shows who has been paged by minute N.
• The CMDB map shows what depends on what, and what breaks if it fails. Your configuration items and their relationships are drawn as a graph. Select an item to highlight everything that depends on it, and see open incidents and firing alerts on each item. Large estates fold by type, and search flies to an item.
• A change plan shows as a flow you can watch while it runs. The plan page draws the dry run, the approval, each step with its check and rollback, and the outcome. The colours update while the plan runs.

Fixed

• A schedule override is always the one paged. On installs whose rotations are kept as coverage, the rotation was answered before any override was read, so the person who took the shift was not the one paged. An override now always wins over the rotation.
• The escalation chain editor describes step delays correctly. A delay is the wait before that step fires, and the first step always fires straight away. The editor now says so, and the total escalation window no longer counts the first step's delay.
• Push can be chosen as a channel in the chain editor. Escalation has always supported it; the editor did not offer it.
• Alert health and Operational health stay hidden from roles that cannot use them. Typing the address opened the page for roles the menu hides it from. The page now refuses them, as the server always did for the data.

Upgrading

After updating, open Fleet → Update all agents. Drive bays, the server model and failed-disk alerts need agent 0.132.0; until a host runs it, its front panel says that no drive-bay report has arrived yet.

Why

You can see at a glance where a problem is, physically and logically, and act on it from the page you are already on. Every change a visual control makes still goes through a change plan with someone else's approval.

A host's Changes history now shows only real changes, and an investigation's evidence shows the right times.

Fixed

• DNS servers no longer fill the Changes history with a "version changed" entry every five minutes. Some services print the current time in front of their version, so every report looked like a new version. Versions are now compared by their number, a real upgrade still shows, and the entries recorded so far that were not a change are removed when you update.
• An investigation's "Listening ports" evidence no longer says it was observed in January 1970. The time the agent reports is now read correctly on the incident page and in the assistant's port lookup.

Nothing changes on an installed system. This release only fixes the checks that run before each release.

Fixed

• The pre-release database drills left a Docker volume behind every time they ran. The HA drill, the restore drill and the migration check start throwaway Postgres containers and removed them without their data volumes, five per run. Each removal now takes its volume with it, and a test keeps every such check that way.

Security release. Update promptly.

Standby now starts investigating an incident the moment it fires, shows what changed on each host, and runs every change to a host as a reviewed plan: previewed with a dry run, approved once, checked after each step, and undone automatically if a check fails.

Added

• A critical or high incident investigates itself as soon as it fires. Standby gathers the affected service's state and recent logs, host metrics around the fire, listening ports, recent agent commands and what changed on the host, then the AI works from that evidence with read-only checks. The incident page shows an Investigation panel with the hypothesis, each piece of evidence linked to its source, and any proposed fix. Paging is never delayed. Settings → AI & automation sets the severity floor, filters and a daily spend cap ($5 by default).
• Every host has a Changes tab showing what changed and when. Packages installed, removed, upgraded or downgraded; services added, started or stopped; config files changed; containers added, removed or re-imaged; ports opened or closed; network interface changes. Each kind of data shows how fresh it is. Changes are kept for 90 days.
• Linux hosts list their Docker and Podman containers. Root-only engine sockets are read through a narrow helper that returns a fixed set of fields; environment variables never leave root, and the agent is never added to the docker group.
• Changes to hosts run as change plans. Each step is previewed with a dry run, the blast radius is shown, and the plan is approved once by someone other than the proposer. Steps run one at a time with a check after each; if a check fails, completed steps are undone in reverse. A preview older than 15 minutes is re-run before approval. The AI now proposes plans instead of single commands.
• Start, stop, restart, enable and disable any service from the host page. Works on systemd, OpenRC and Windows hosts. Each action becomes a one-step plan; the agent refuses to stop itself.
• Every action that changes a host can be rehearsed first. Package installs, removals and upgrades simulate on apt, apk, dnf, zypper and pacman; firewall, SSH key, sshd hardening, network, hostname and timezone changes preview what they would do.
• Packages can be installed and removed on Alpine, Fedora/RHEL-family, SUSE and Arch hosts. Previously Debian and Ubuntu only. Package inventories are now collected from apk and rpm hosts as well.
• The paired billing platform's staff audit log can be streamed into Standby. Every entry's hash is re-checked and chained, missing entries are fetched, and tampering, two-factor being turned off, bursts of failed sign-ins and role changes raise incidents. A searchable screen shows the log and a key fingerprint to match against the billing platform's own screen. Kept one year by default.

Changed

• Sending a command to a host needs the permission for that kind of action. Permissions are now split by action family, read or change. Roles that could send commands keep every ability they had; API tokens need the exact scope.
• Change freezes now block changes to hosts. During a freeze, any action that changes a host is refused unless someone with the override permission gives a reason. Reads and dry runs are never blocked. Blocking an IP and containing a host still go through; unblocking an IP waits until the freeze ends.
• Automatic IP bans, quarantines and antivirus scans run under the automation policy with daily caps. They remain automatic (caps 1000 / 200 / 200 per day) and can be adjusted on the Remediation page.

Fixed

• Restoring the database after a failed update no longer fails with "out of shared memory". The restore now loads the backup into a fresh database and swaps it in only once it is complete and checked, so a failure leaves the database untouched. The operator restore command works the same way. New installs also raise PostgreSQL's lock limit; existing installs get it at their next PostgreSQL restart.

Security

• Web framework, email library and a pattern-matching library updated for published advisories. fastify 5.12.5 (denial of service; request body replacement), nodemailer 10.0.13 in the admin app and status page (SMTP credential disclosure across transports; stack exhaustion), brace-expansion 5.0.12 (denial of service).

Upgrading

Update the host agents to 0.131.0 (Fleet → Update all agents). Dry runs, service control, containers and the Changes tab need it; Standby never sends a dry run to an older agent. If you use change freezes, check your freeze windows: they now block changes to hosts, including Standby's own automations (unblocking an IP waits until the freeze ends).

Why

When you are paged, the evidence is already gathered, and nothing changes on a server without a preview and an approval.

Applications can now show the full stack behind a web server whose configuration file only root can read, without the agent ever seeing a secret from that file.

Fixed

• Applications shows the upstreams of a site whose nginx, Apache or LiteSpeed config only root can read. This includes Standby's own site on installs made before the installer wrote it world-readable. Previously the stack stopped at the server with "cannot read …". The host agent now reads such a file through a new read-only root helper that only reads inside the web-server config directories, never opens a key, certificate or password file, and removes every value it does not need (headers, passwords, tokens, comments) before the agent sees the text.
• Standby's own nginx site file is made world-readable (0644) on update if an earlier install left it root-only. It holds no secret: server names, ports, upstream addresses and certificate paths.
• A backend address written as http://user:password@host:port no longer carries the password into the discovered stack.

Security

• The telemetry host's nginx file, which contains its access tokens, is now written readable by root only. This applies to newly set-up telemetry hosts; see the upgrade note for existing ones.
• The HTTP client library (undici) is updated to 8.11.2 for two denial-of-service advisories.

Upgrading

• Update the host agents (Fleet → Update all agents), then re-scan the application on Applications. The "cannot read" note disappears.
• On an existing telemetry host, run sudo chmod 600 /etc/nginx/conf.d/standby-telemetry.conf once.

Fixed

• External scan and Downloads sat in a narrow centred column. They set their own width and ignored your content-width setting. They now use the full content area like every other page.
• Page titles are one size. 21 compliance and audit pages (Frameworks, Controls, Statement of Applicability, External audits, Internal audits, Management review, Objectives, Nonconformities, Cyber Essentials and others), External scan, IP control, Auto-remediation and several list pages had smaller titles, some with the description squeezed onto the title line. They now use the standard title with the description underneath and the actions on the right.

Added

• Live scan progress. A running scan shows which step it is on (open ports → web discovery → vulnerability templates → TLS grading → uploading) and what it has found so far, updated every few seconds. Click any run to see its findings.
• Hosts with scanner engines. The scanner card lists every host the engines were installed on, including earlier installs, with Remove (deletes the engines from that host) and Use as scanner. Installing asks for confirmation and names the host it will install on.

Fixed

• An external scan of a site behind a CDN failed and lost every finding. A name with several addresses made the engines report the same issue once per address, and saving the second copy failed the whole run. Duplicates are now folded into one finding (the worst severity wins, and the count is shown as ×N).
• A failed scan now says why, under the run in Recent runs.
• The scanner node picker showed "— none —" while a scanner node was set.
• Applications dropped a server from the stack when its agent answered but could not read the site's configuration file. The server and its web server are now kept, with a note naming the file that could not be read.

Upgrading

• If you installed the engines on the wrong host, open Security engineering → External scan and click Remove on that host.

Fixed

• A stopped or crashed service never paged. Standby promises to page when a detected web server, database, cache or mail service stops. It could not:
  • The service inventory was only refreshed when someone pressed Scan on the Services page, so it could be months old. Standby now refreshes it from every server every 5 minutes (service_health.detect_interval_sec changes this).
  • A crashed service (failed) was ignored. It now pages.
  • A stopped service disappeared from the inventory and looked uninstalled, which closed its alert. The host agent (0.129.0) now reports a service that is switched on but not running as stopped. Agents update themselves.
  • Setting the alert delay (service_health.down.debounce_sec) to 0 was read as 180 seconds.
• Applications showed "OK" when nothing monitored them. A result from the last scan, up to a day old, counted as a healthy signal. An application with no website check now says "not monitored" until you create its monitors.
• Scanning the site Standby itself runs on failed. The server answered its own name with a local address, so the scan refused it as private and listed a phantom "127.0.1.1" host. Discovery now asks public DNS when that happens.
• A failing keyword check now says which keyword is missing instead of substring_missing.

Upgrading

• The keyword field on an HTTP check is optional. If an application is down because the page "does not contain the keyword", remove that monitor and create it again with the field empty.

Fixed

• Application discovery missed services that rename their process (host agent 0.128.0). A Node or Python service whose process name is not literally "node" or "python" — including Standby's own services — was skipped, so its dependencies were never checked. The agent now also recognises the program by its executable, and uses its privileged helper to see every running application. Agents update themselves.

Security

• Updated fast-uri (used by the API's request validation) to fix a newly published high-severity advisory (GHSA-qw65-cvwx-89v3).

Fixed

• VIR vulnerability findings could belong to a different server. Standby identified each host to VIR by a small number, and VIR read that number as its own internal row. Each host could therefore show another machine's results, for example 500 kernel vulnerabilities for a kernel the server does not run. Standby now uses each host's unique ID. The wrongly attributed findings are removed on upgrade, and the next matching run (within 30 minutes) recreates the correct ones.
• Kernel findings on distribution kernels. Kernels built by a Linux distribution (Ubuntu, Debian, Alpine and others) carry backported fixes that upstream version numbers do not show. Only plain upstream kernels are now matched on upstream versions; distribution kernels are covered by the distribution's own package advisories.

Fixed

• Upgrading to 0.13.0 could make the database run out of memory. Operating-system vulnerability matching stored the whole advisory feed as one database value. Standby now keeps only fixed advisories for packages your servers have, one per row, and clears the oversized data on upgrade.
• PostgreSQL now restarts on its own if the system kills it, and the kernel's out-of-memory killer picks almost anything else before it. The update applies this to existing installs. Before, an out-of-memory kill left the database down until someone started it by hand.
• When the database is unreachable, the console says so ("Standby cannot reach its database", with Try again) instead of showing "Redirecting to login…" forever.

Changed

• Service health, service threshold and SLO alerts now page on-call out of the box. They used to open incidents that paged nobody until someone switched each source on. A source an operator deliberately switched off stays off.
• Applications presets:
  • Zephyr is monitored through its readiness endpoint. When it is unhealthy, the alert names what failed (database or Redis).
  • The main RepoMade server gets a health check, as its update edge already had.

Fixed

• Pushing to Zephyr, and the "paired billing platform" status, could pick a kstack pairing instead of the Zephyr one.
• Billing auto-pairing on first boot was skipped whenever any pairing existed, including a kstack one.
• DNS drift checking asked a secondary's primary for its SOA instead of the secondary itself, so a stuck secondary always looked in sync.
• Calls to the status-page app now time out instead of hanging.

Added

• Applications (Observability → Applications).
  • Add a website's URL and scan it. Standby checks DNS, HTTP, TLS and the technology from outside. On your enrolled servers it traces the stack: which server and web-server block serve it, what that passes requests to (PHP-FPM, Node.js, pm2, Docker), and which database, cache and DNS node it uses — addresses only, never passwords.
  • See the stack as a graph and tick what to monitor: website check, certificate expiry, service health, thresholds, dashboard, SLO, and who gets paged. Every monitor it creates can be undone.
  • An application health page, with incidents grouped by application and a "Send test alert" button. Scheduled re-scans tell you when the stack changes.
  • One-click setup for systems Standby already knows: kstack control planes, Zephyr, RepoMade, status and probe nodes, PowerDNS nodes and this Standby install.
• Application vulnerabilities (CVE → Applications, and an Applications tab on each host).
  • The agent finds applications on each server and reads their dependency lockfiles (npm, yarn, pnpm, Composer, pip/Poetry/Pipenv, Bundler, Go, Cargo, Maven/Gradle, NuGet) and WordPress core, plugins and themes.
  • VIR matches them against its vulnerability database. Standby re-checks every match before reporting it.
  • Each application shows its vulnerable dependencies, fixed versions, and whether a dependency is direct or indirect.
  • Download a CycloneDX SBOM per application, and link it as compliance evidence.
• Nine more frameworks (25 in total): ISO 22301:2019, ISO/IEC 27017:2026, ISO/IEC 27018:2025, ISO/IEC 27701:2025, NIST SP 800-53 Rev 5 (moderate baseline), the HIPAA Security Rule, the ACSC Essential Eight and UK GDPR + Data Protection Act 2018. They start un-adopted; add them on Compliance → Frameworks. A NIST 800-171 attestation now also counts for the 49 matching NIST 800-53 controls.
• The agent detects Node.js, Redis and PHP-FPM.

Fixed

• Pinning VIR's public key (VIR_PUBLIC_KEY_HEX) made every VIR call fail as a bad signature.

Upgrading

• Host agent 0.127.0. Agents update themselves. The Applications stack view and application dependency scanning need it; until a host runs it, those features say "needs agentd 0.127.0" instead of showing nothing.
• Vulnerability matching through VIR is now on by default when VIR is configured (switch it off with cve.vir_correlate.enabled = false). Newly found vulnerabilities on the CISA "actively exploited" list page on-call.
• Operating-system packages are now matched locally from VIR's distro advisories. Sending the package list to VIR had never produced a match.
• A self-hosted or plain-http VIR needs VIR_ALLOW_PRIVATE=1.

Added

• Frameworks page and unified controls.
  • Choose the frameworks your organisation adopts, with a scope statement for each. The dashboard, SoA, exports, auditor pack and trust page follow it.
  • One attestation or piece of evidence counts across frameworks: NIST 800-171 and CMMC Level 2 now share all 110 controls.
  • Every framework shows its version, e.g. "SOC 2 (TSC 2017, rev. 2022)".
• Control owners. Every control gets an owner, a reviewer and a review cycle, with a My controls list and overdue reminders.
• External audits.
  • An engagement covers the audit type (ISO, SOC 2, Cyber Essentials, PCI), period, auditing firm and lead auditor.
  • A scoped auditor portal: the auditor sees only that audit — per framework and total, controls, evidence, policies and the SoA — and nothing else in Standby. Access expires and can be revoked.
  • Evidence requests go to the control owner. Accepted evidence lands on the control and counts for every framework sharing it. Type II audits get population and sample requests.
  • Findings open a CAPA; the auditor signs off closure.
  • A certificates register with expiry and surveillance reminders, which can drive your trust-page badges.
• Risk management. A configurable scoring matrix and risk appetite, inherent and residual risk, treatment plans, formal acceptance with an approver and an expiry, links to controls, a heat map and review reminders.
• Management review (ISO 27001 9.3), with inputs pre-filled from Standby: audits, incidents, CAPA, objectives, risks and suppliers.
• ISMS objectives (6.2), measured from Standby metrics where possible.
• Internal audit programme (9.2): an annual plan across your adopted frameworks, generated checklists, an independence check (nobody audits controls they own) and findings into CAPA.
• Policy lifecycle: versions, review and approval, and re-acknowledgement when a new version is published.
• Cyber Essentials v3.3 readiness (Compliance → Cyber Essentials).
  • Standby proposes answers to the IASME "Danzell" question set from its own data, for you to confirm and paste into the IASME portal, with a board sign-off record.
  • A CE Plus pre-flight runs the assessor's tests on every in-scope device — patches within 14 days, supported OS, anti-malware, firewall, MFA, external scan — and says "Ready for CE Plus" only when nothing blocks it.
  • The auditor portal shows the same result.
• External vulnerability scanning.
  • Standby scans your internet-facing servers and sites from a scanner node outside your network, using open-source engines.
  • Targets must be yours: an enrolled server, a domain you prove with a DNS record, or an address a super admin vouches for.
  • Weekly and on demand. A new critical or high finding opens an incident.
  • Each run produces a signed PDF report and an attack-surface map, and counts as evidence for Cyber Essentials, ISO 27001 and SOC 2.
  • Standby never bans its own scanner.
  • You can also import results from other scanners, including Detectify.

Fixed

• On narrow screens the notification bell covered the close button of side panels.
• The notifications stream no longer hangs when Redis is down.

Upgrading

• Frameworks are now adopted, not just listed. On upgrade your install adopts every framework it already has results for (all 16 on most installs), so nothing you relied on disappears. Go to Compliance → Frameworks to un-adopt what you do not need and write a scope statement for each.
• New policies need approval. Creating a policy now makes a draft; someone other than its author approves it before it is published. Your existing policies and every acknowledgement are kept, tied to the version they were given for.
• Compliance managers can now keep the risk register and draft policies. Accepting a risk and approving a policy stay with Security admins.
• The kstack pairing now receives scores for adopted frameworks only.

Changed

• Third-party licence notices updated.

Fixed

• Banners no longer cover the menu on phones. Site-wide notices, such as SMS and voice not being configured, paging problems and licence warnings, now sit below the top bar instead of painting over an open menu drawer.

Changed

• Clearer handling of SMS and voice without a provider. If no Bird or Twilio provider is configured, SMS and voice show as "not configured" with an amber warning instead of raising a pager alarm. Escalation steps that rely only on SMS or voice fall back to email and push, so alerts still reach you. This release also includes everything in v0.10.1.

Removed

• Dialpad is no longer supported. Dialpad settings, credentials and webhooks are cleared for you when you upgrade, and any pager alarms raised by Dialpad are closed automatically.

Added

• Suspend and resume from Standby. Any kstack resource, or a whole customer account, can now be suspended and brought back again when you're ready. Requires kstack v1.203.0 or later.

Changed

• Hosting has its own place in the sidebar. Hosting pages are now grouped together in the sidebar, and kstack pages carry the kstack brand mark so you can tell at a glance where you are.

Fixed

• DNS drift monitoring is back. Standby again compares the zones held by your connected DNS providers against the public nameserver set and its own DNS nodes, checking every 10 minutes, so a zone that falls out of step is spotted rather than left to linger. An alert is only raised after a second consecutive failed check, which keeps momentary blips quiet, and any alert still open stays open across a restart until the underlying drift is actually cleared.