• NIS2 deadlines follow the directive. The final report is due one month after the notification, as Article 23 says, not 30 days: from mid-January to the end of February, 30 days gave up to two days more than the law. The NIS2 panel shows the moment the deadlines count from, and you pick it from a calendar. A time in the future is refused, and each change of it is kept in the incident's timeline.
• NIS2 reports go only where you meant. The CSIRT country is no longer preset to Germany: choose it before you download or send. Email to CSIRT and marking a stage as filed each ask you to confirm first, and the email confirmation names every CSIRT that will receive it. A report lists the impacted Member States, and the email goes to them, only while Cross-border impact is on. Cancel drops your unsaved NIS2 changes; before, they went out with the next save.
• Better NIS2 report files. The German and French layouts name every sector in their own language. A control character pasted into a title or a description no longer makes the Italian XML unreadable. The email calls the report's SHA-256 a checksum, not a signature. Each NIS2 save and each filing now shows in the Activity Log, and on a phone the NIS2 panel fits the screen.

• Going back after an update says exactly what it did, and release notes read more clearly. When an earlier rollback was cut off while it restored the database, the next run now first warns that the database may hold all, part or none of the backup, even when it then stops with an error, and if the backup file is gone it tells you to restore the database from another backup. After a cut-off restore, if stopping the services fails, the next run now names the services that may still run on that database and shows the command that stops them. A rollback now says the database was not changed only when that is certain, and says the errors came from the database only when they did. The rollback after a failed update, the automatic one or the one an air-gapped update tells you to run, does the same: when it cannot tell whether it restored the database, it now says so and shows the command that goes back by hand. In Settings → Updates, a release whose notes were withdrawn after publishing shows no text instead of its old notes, and headings inside a release's notes show smaller than the release's own version heading.

• Alert mails say what is most likely wrong, where to see it and how to fix it. Each alert mail lists the likely causes, the most likely first. Where AtlasEye shows the problem, the first step names that page and the link in the mail opens it. The next step is the fix: in AtlasEye where it can be done there, otherwise a command, with the install folder to run it in (/opt/atlaseye). A log command comes only last, for when the alert still fires, with its output to send to support. Slow-request mails now say whether the whole API is slow or one endpoint, what that endpoint waits on (for example the AI provider, the licence server, a device, Prometheus, a notification channel, the identity provider or OpenSearch) and how many requests it served; when the endpoint served only a few requests, the mail says that a few slow ones are enough to fire it. When the other endpoints answer in time and the slow one waits on nothing outside AtlasEye, the mail names that endpoint's own work first, most often a database query. For an endpoint that waits on the licence server, the mail points to the tag beside Last Heartbeat in Settings → Licensing: where it reads "unreachable", it says to allow HTTPS to the licence server through the firewall or proxy; where it reads "airgap" (an air-gapped install), it says to leave the firewall as it is. A slow health check on an air-gapped install is expected and does no harm: the health check still waits for the licence server, which never answers there. A slow heartbeat on an air-gapped install is this server's own work, because the heartbeat never contacts the licence server there; the mail says so and points to Host and Database in System Health. A failing task that only PostgreSQL can stop points to PostgreSQL and the data disk: the clean-ups of old incidents, alerts, notification log entries, DNS snapshots and sign-in events, the status page uptime sample, and the checks that carry on when a host, site or search they reach fails (certificate expiry, service rediscovery, configuration snapshots, temporary redirects, Web Analytics traffic alerts and syslog threat alerts). The other clean-ups, the scheduled reports, the syslog alert rules and the container log check catch their own errors, so their mail names an error in AtlasEye. The Web Analytics retention mail points to each site's Retention (days) in Manage sites.

• Going back after an update restores the database whole or not at all, and never runs while an update from the same directory runs. A rollback now puts the database backup back in one step: when it is cut off, the database stays as the update left it instead of holding part of the backup. Before anything changes, a rollback refuses a backup that holds something a normal backup never contains, or one cut off before its end. Run by hand, it also checks that the disk has room to unpack the backup, and it stops every AtlasEye service except the database while it runs (on an install that updates online, the updater keeps running); a service the previous version did not have stays stopped, and the rollback names it with the commands that remove it or start it again. An update, a rollback or Prune Now started while another of them runs from the same directory refuses to start. On an air-gapped install each bundle directory counts on its own, and Prune Now can still start while an update runs, so do not start it then. An update also refuses while a rollback from the same directory has not finished, and shows the command that finishes it; on an air-gapped install, finish a rollback before you run the update of another bundle. Before the rollback puts back the previous version's compose files, it keeps a copy of the newer ones and names the ones changed since the update; if it cannot make that copy, it says so and leaves the newer files in place, and the previous version starts with them. When the automatic rollback after a failed update does not finish, the update shows the full command that finishes it; a rollback you run by hand says what to do next. A rollback you run by hand after an update that never finished now also asks you to type ROLLBACK first, and says that the update never finished. After an air-gapped update has rolled itself back, a rollback run by hand no longer restores the backup a second time: there is nothing left to go back to.

• The AI assistant asks before it runs a command, and is clearer about what it sends and why it cannot answer. When a command on a device would help, the assistant now proposes it on a card in the chat that shows the host, user and exact command; it runs only after a Full Access admin approves it, once, and an unanswered card expires after 10 minutes. The chat masks text that looks like a password or key in your messages and chat titles, also in conversations saved before this update: the update rewrites saved chats and their titles for good. Masking matches patterns: it can miss a password, so do not type passwords into the chat, and it can also hide ordinary text that looks like a password. The assistant asks for an SSH password only on the card, when the device has no stored login; that password is used for that one login and is never saved or shown to the AI model. Each role sees only the assistant actions its permissions allow. The daily briefing, Auto-correlate and rule-based predictions are now labelled as fixed rules rather than AI, and Auto-correlate shows the groups before it creates any incident. When the assistant cannot answer, it says why: AI not set up or turned off, a rejected key, a timeout, a rate limit, a network problem or the daily spending limit. Calls on a paid model without a price show "price unknown" instead of $0, and the AI chat no longer carries a vendor name.

• The syslog rate-limit alert behaves the same for every window length. The alert "Syslog senders are over the per-sender limit" now counts the messages over the limit, in Enforce and Monitor mode. Its mail is now titled "Over the per-sender limit: syslog messages", followed by how many messages went over the limit in the last 5 minutes. It fires when messages have gone over the limit at least once in every 5 minutes for 15 minutes, so a flood shorter than about 10 minutes raises no alert. Before, its timing depended on the window you set: with a one-hour window a single short burst could raise it up to 75 minutes later, and with a window under 10 seconds a burst could go unseen. A sender is named only once its window has ended, so the mail and the list "Senders over the limit (last hour)" can name no sender while the alert is active, and with a long window the mail can name a sender of an earlier window. "Now" in that list means the sender went over the limit in the last completed window, which with a long window can have ended up to an hour ago. If Apply Update warned that it left the alert rules file as it is because it was edited on your server, take this release's copy with the command in that warning. If that warning said this release's copy could not be parked beside it, there is no command in it: the next update tries to park its own copy there again, and when it can, its warning gives the command. If the same warning comes back, check the free disk space and that the folder of that file belongs to root, as after a standard install. Until then this alert keeps its old rule, and the number in its mail counts senders, not messages. If Apply Update said it left that file as it is for another reason, or that it could not fetch this release's installer files (see the next item), the next update tries again. Keep Prometheus running, because the update checks the new file in Prometheus first. If it reported an error that it could not put the file back, run the command in that error first. Until then, too, the number in the mail can count senders.

• An update that cannot fetch its installer files says all it leaves alone. If the Apply Update log says "atlaseye-dist pull failed", or that the signed manifest "pins no atlaseye-dist digest", the update could not fetch the release's installer files. It then leaves the compose files and the monitoring configuration as they are too, not only the host scripts it names, and the next update tries again. From the update after this one, that message names all three.

• The free-space checks of an update and of the installer say GiB. Before it downloads the new version, an update checks the free disk space on the server and writes the result to the update log, or to your terminal when you run scripts/update.sh yourself. The air-gapped update (scripts/update_airgap.sh) checks the same limit, added to the size of the images it loads, before it loads them. Both gave the sizes in GB, but they are GiB, the unit the Apply Update dialog uses for the same limit. Both now say GiB. The installer counts the free space on Docker's disk in GiB too: its disk check now gives that space, the 30 GiB minimum and the size below which it warns in GiB, and so does the "Hard floors" note under the sizing table in the documentation and on the portal's downloads page. The note also says that these checks read the disk sizes of the table as GiB, and atlaseye status and atlaseye profile show give the free space in GiB too.

• An update from a shell on the host can take the release's own scripts. sudo bash scripts/update.sh --refresh-installer-files takes this release's scripts, compose files and monitoring configuration, as Apply Update does. This keeps them current on a host where Apply Update is not supported, such as one with Docker userns-remap. Without the flag, a run from a shell on the host leaves them as they are and now says so, instead of downloading them for nothing. In a git checkout the flag is refused, because git owns those files there.

• An update from a shell on the host checks the right addresses. The checks at the end of an update asked addresses that exist only inside the updater, so from a shell on the host an update that had gone fine rolled itself back unless four settings were set by hand. The update now checks this host's own ports, and so does scripts/rollback.sh. The four settings still override them.

• A failed update rolls back while the new version runs. When an update failed after the new version had started, the automatic rollback could not restore the database while that version still used it, and gave up with the database unchanged. It now stops the new version first, as a rollback by hand already did, and starts it again if the database cannot be restored.

• The alert mail and Syslog settings now name the senders over the per-sender limit. When senders go over the ingestion rate limit, the alert mail now lists their addresses, up to 10. Syslog & Security → Security Settings → Ingestion Rate Limit has a new list, "Senders over the limit (last hour)": each sender, the most messages it sent over the limit in one window, the name of its allowlist entry and whether it is over the limit right now. The list refreshes every minute, so you no longer need the collector log to find a noisy sender. When many senders go over the limit at once, which often means forged source addresses, the list names 20 and counts the rest on one line.

• Notification emails have a new layout. Emails from a notification channel now show the AtlasEye logo and a coloured bar for how urgent the message is. When Public App URL is set under Settings → General, they also have an "Open in AtlasEye" button. They carry a plain-text version and the Date and Message-ID headers that mail servers expect, and they come from "AtlasEye Alerts".
• Telegram notifications are easier to read. The first line starts with an emoji for the level, and links no longer expand into previews. Recovery messages and AI capacity forecasts arrive without a notification sound.
• Webhook notifications carry a language field. The other fields keep their names; the level of some alerts changes, as listed below.
• The Test button sends a complete sample message. Testing a notification channel now sends a message with every part a real alert has: details, a step with a command, and the link to AtlasEye. It is written in the channel's Message Language.

• Apply Update now also keeps the alert rules and the monitoring configuration up to date. An update used to leave the built-in alert rules and the configuration of the metrics and alerting services exactly as they were installed, so new and corrected alerts reached new installations only. Starting with the update after the one that installs this version, Apply Update brings these files up to date as well, just before it restarts the services. Each new version is checked by the running service first; if the check rejects it, the current file stays in use. A file you changed on the server is left as it is: the new version is placed next to it, and the update log names the file and the one command that takes the new version when you are ready.

• Reinstalling no longer stops later updates from refreshing the configuration. After the installer was run again over an existing installation, every later update took the freshly installed service definitions and monitoring configuration for files you had changed: it left them as they were, placed its own copies next to them and warned about changes you never made. The installer now resets that record once it has verified the files, so the next update brings them up to date as usual.

• Air-gap updates now bring the new alert rules and monitoring configuration. Prometheus and Alertmanager kept reading their configuration from the directory they were first started from, because update_airgap.sh never restarted them from the new bundle directory. So an offline server never got a release's new alert rules or Prometheus configuration, and monitoring targets added after an update, for example by Auto Setup (SSH) on a device's Containers tab, were never collected. Deleting that old directory also stopped both from starting. The update now moves both to the new bundle directory. A file that is still as installed takes the new release's copy, once Prometheus or Alertmanager accepts it. A file you edited keeps your edits: the release's copy is saved next to it with .release added to its name, and the update prints the command that puts it in place. Make monitoring edits in the newest bundle directory from now on. A rollback leaves both on the new bundle directory, so keep that directory.

• Alert Thresholds now tells the truth about a failed Prometheus reload. When Regenerate & reload Prometheus wrote the alert rules but Prometheus did not reload, the warning said the rules would be picked up on the next scan, and Help said the same. Prometheus never rescans them on its own: the new thresholds wait for a successful reload or a Prometheus restart. The warning and Help now say so, and tell you to press the button again.

• An alert override edit sent to the wrong alert's address is now refused before anything changes. Through the API, editing an override under an alert it does not belong to answered "not found", but the change had already been saved and applied to the other alert. The request is now rejected first, as deleting one already was.

• Signing in no longer makes the rest of the interface pause. Signing in, entering a recovery code, changing a password, setting up or turning off two-factor authentication and creating new recovery codes no longer make the rest of the interface pause for a moment on small servers, for you or for anyone else using it at the time. The same goes for an administrator creating a user or setting a user's password. Nothing changes in how these work.

• The interface no longer pauses for everyone while one slow page loads. Checking a port on a host that does not answer, loading a router's firewall block list, signing in through single sign-on or opening a user's activity history could make the whole interface pause, for you and for anyone else using it at the time, until that one request finished. These now run alongside everything else. Nothing changes in how they work.

• A factory reset now completes, whoever starts it. System Reset (Factory Defaults) now deletes the data, restores the default administrator and adds an entry to the audit log that names the administrator who started it. If a step fails, nothing is deleted. Before, the reset stopped with an error: usually before deleting anything, but on some older installations only after the data was already deleted, when an administrator other than the first account started it.

• Actions recorded without a user account now say who did them. The Activity Log, its page exports and its details panel, and the dashboard's Recent Activity showed "User null", "User n/a" or a bare "User" for them. They now show "system", and the factory reset entry shows the administrator who started it. An action by a user who has since been deleted shows "User" and that user's ID, also in the history of an IP address or range, where it showed "system".

• In the Activity Log, row numbers continue across pages. On the second page and later they started again at 1. Each entry also shows the name of the item it is about next to its ID again, as its details panel already did.

• The factory-reset dialog shows its title correctly, and the Arabic interface shows it in Arabic. The dialog that System Reset (Factory Defaults) opens under Settings → System showed garbled characters before "DANGER" in its title, in English and in Arabic. It now shows a warning sign there. In Arabic, the card and its dialog were in English; they are now in Arabic, and the word you type to confirm is still RESET. In Portuguese, the Âmbito/Zona label of the IP address form also showed garbled characters; it now reads correctly.

• Disable in the Users list shows a stop icon. The Disable action in the Users list, and in the panel that opens when you click a user, showed a trash can. Disabling keeps the account: it signs the user out and blocks sign-in until you enable the account again. The action now shows a stop icon instead.

• An update now restores the OpenSearch Dashboards service account when it is missing. If the kibanaserver account had been deleted from OpenSearch, an update reported success while OpenSearch Dashboards could not sign in. The update now creates the account again with the Dashboards password from your .env file and restarts Dashboards so that it signs in. When it cannot, for example because you changed the Dashboards login yourself, the update now shows a warning instead of success; the update itself still stands.
• The organisation name from the first sign-in wizard is now saved on a new install. Until now it was lost whenever no licence had been activated yet, which is the case on every new install: the wizard reported that the save failed and moved on to the password. The name is now saved before a licence is activated too, so it no longer has to be set again in Settings > General.

• Your own address opens the sign-in page. Opening AtlasEye at your own address showed the vendor's marketing page first. The sign-in page now opens at every address except the vendor's own marketing site.

• About says who to contact. About used to show every user the vendor's support address in one Support card. It now has four cards. Get help shows your organisation's help desk. Report a vulnerability shows the manufacturer's security contact. Manufacturer shows who makes the product. Vendor contacts, which only full admins see, lists the vendor's support, sales and legal contacts and its privacy policy, and now holds the Download diagnostic bundle and Config snapshot buttons.

• Support Email is your help desk. The Support Email field under Settings → General is your organisation's own help desk, for your users. About → Get help, the sign-in page, the app footer and the public status page show it. When it is empty, About tells users to ask an administrator and gives full admins a link to set it. It never falls back to a vendor address, and the diagnostic bundle that you send to the vendor leaves it out.

• Your public pages stop linking the vendor's privacy policy. With no Privacy Policy URL set, the sign-in page linked the vendor's Privacy page instead, and the public status page always linked the vendor's EULA and Privacy pages. Those pages cover the vendor's licence service, not your users or your visitors. The sign-in page and the status page now link your own Privacy Policy URL and help desk, each only when it is set.

• Notices where data goes to the vendor. The demo licence form under Settings → Licensing now names who receives your details, why, the licence service's privacy policy and where to send privacy questions. The Public Status Mirror card warns you not to put personal data in the banner or in a maintenance message: both go to the vendor and appear at the public mirror link.

• The trial-expired dialog and the lock screen give real addresses. Contact sales in the trial-expired dialog now opens an email to your vendor's sales address, or to your reseller's when it has set one. The button is hidden when no address is available. The integrity lock screen now shows the support address to send the support code to.

• The SSH pop-out warning names your address. When the browser blocks the SSH terminal's pop-out window, the warning now tells you to allow pop-ups for your own address instead of the vendor's.

• Your address no longer serves the vendor's security.txt. Every installation published a security.txt that told security researchers to send reports about your domain to the vendor, and promised a response time that no policy backs. It is gone. To report a security flaw in AtlasEye itself, use the contact under About → Report a vulnerability.

• The compliance documents no longer promise response times. The evidence pack and the SOC 2 and NIS2 documents promised to acknowledge vulnerability reports within 3 or 10 business days, or 24 and 72 hours. No policy backed those times. The coordinated vulnerability disclosure policy, which is still pending, will set them. The evidence pack also offered a data processing agreement. It now says, as EULA v1.3 section 7.3 and Privacy Policy v1.2 section 2.1 do, that ordinary operation needs none.

• Getting help, in Help and in the install guide. Help → Shortcuts & support has a Who to contact card: your help desk first, security flaws to the manufacturer's security contact, and for full admins the vendor's contacts under About → Vendor contacts. INSTALL.md has a new Getting help section with the support and security contacts. Resellers can set their own support, support portal and sales contacts; .env.example describes the settings.

• Help now has a server runbook. Administrators who can open Settings → System see a new Help tab, Server runbook. It lists the commands to run on the server that hosts AtlasEye: health checks, logs, the switches to use when a setting cannot be reached in the web interface, restarts, updates, the data services, the TLS certificate, disk space, and what to send with a support request. Every command has a copy button and reads left to right in every language. Steps that interrupt service or can lose data are marked, and the least disruptive option comes first. The Maintenance, Updates, System, Backup & Archive and About guides, the troubleshooting answers that need the server, and the offline update card under Settings → Updates link to the matching section.

• Report a problem from inside AtlasEye. Choose Report a problem in the menu behind your name, on Help → Shortcuts & support, on About → Get help, or on the screen shown when a page crashes. Describe what went wrong and review exactly what the report contains before anything leaves your installation. Technical details are optional; your licence key, sign-in tokens and values written as password=… are masked. Full admins send the report to AtlasEye support and get a reference starting with PR- to quote. Everyone can download the report. Email report appears when there is an address to write to: AtlasEye support's for full admins, otherwise your help desk's once your organisation has set a support email. An air-gapped installation, or one without an activated licence, downloads or emails the report instead.

• Chat and Recent Diagnostics keep their history on every installation. The database of an installation first set up by version 1.1.0 or later had no tables for chat conversations or for the diagnostics history of the Tools page. Opening AI Agent → Chat showed "Failed to load chat history." and its list of past conversations stayed empty, and Recent Diagnostics on the Tools page did not keep a run past a page reload. Updating creates the missing tables. An installation that already has them keeps its conversations and diagnostics history as they are.

• Only the admin who opened a web terminal session can close it. Through the API, any admin with terminal access could end another admin's open SSH session by its id. Each session now remembers who opened it, and a close request from anyone else leaves it running.

• An incident only accepts alerts you are allowed to work on. Through the API, a user limited to some devices could link any alert to an incident they could reach, including alerts on devices outside their access and alerts that do not exist. Each linked alert now needs the same access as acknowledging it.

• Alert Thresholds now warns when a saved change did not reach Prometheus. Saving a threshold card, or adding, editing or deleting a per-target override, stores the change and asks Prometheus to reload its alert rules. When that reload failed, the panel still said the change was saved, while Prometheus kept alerting on the previous values. You now see a warning instead: the change is saved, the previous values stay active until a reload succeeds, and Regenerate & reload Prometheus tries the reload again.

• New AtlasEye logo. The sidebar, the sign-in page and the public status page show the new AtlasEye logo. The browser tab icon, the home-screen icon on phones and tablets, and desktop alert notifications use the new AtlasEye mark.

• Your organisation's name is shown instead of an uploaded logo. Settings → General no longer offers uploading an organisation logo, brand mark or favicon: every installation shows the AtlasEye logo. The organisation name you set there appears as text beside it: in the sidebar (hover the logo while the sidebar is collapsed), on the sign-in page, on the public status page and in the browser tab title. The two header colour settings go with the upload; the name now takes the sidebar's own colours. Logos uploaded under earlier releases stay on the server and in backups, but are no longer shown.

• Notification History shows forecast and resolved messages. Both have their own colour and name in the Level column, and the level filter can select them.

• Status page emails have the new layout. The email that confirms a subscription to the status page, and the emails subscribers get when the status banner changes, now look like the other notification emails: the AtlasEye logo, a coloured bar for the state, and a button that confirms the subscription or opens the status page (for banner updates this needs Public App URL under Settings → General). They are written in the Default Language set under Settings → General, and their times use the system time zone and name it. When an incident is resolved, the email says when it started, when it ended and how long it lasted, instead of repeating the problem.

• NIS2 reports emailed to a CSIRT have the new layout. The email shows the AtlasEye logo and has a plain-text version. The report text and the signed attachment are exactly as before.

• Each notification channel has a Message Language. Emails, Telegram messages and webhook texts from a channel, including the Test Connection sample, are written in the language chosen for it. The default, System language, follows the Default Language under Settings → General. Device, container and site names, IP addresses, commands and the text of your own Prometheus alert rules are never translated. Times use the system time zone and name it.
• Device, threshold, disk space and SLA notifications are clearer and in your language. The messages that a device is down, degraded or back up, that a metric threshold or the disk space limit was crossed or is back to normal, and the monthly SLA report now use the new layout and the language of each notification channel. They list the facts: the device and its address, the measured value against the threshold, the failing services, and what to check next. A "back to normal" message says when the problem started, when it ended and how long it lasted, and it arrives in the same email thread, or as a Telegram reply, as the alert it closes. A device that goes from degraded to down and then recovers is one thread, and the duration covers the whole problem. Webhooks now receive the level critical for a device that is down and for a critical threshold or disk space alert (it was error), warning for a degraded device (it was error), and resolved for recoveries (it was info). The first successful check of a new device and the SLA report arrive in Telegram without a notification sound.
• Four more alerts arrive in each channel's language. Brute-force sign-in alerts, syslog alert rules, AI log analysis alerts and AI capacity forecasts now use the new message layout and the language of the notification channel, or the Default Language set under Settings → General. Rule names, queries and log lines are shown exactly as written. A brute-force alert now says whether the targeted account is locked, and for how long. The two AI alerts contain only numbers that AtlasEye counted or calculated; the AI's own explanation stays on the Syslog Analytics page and in AI Predictions on the Dashboard. An AI capacity forecast is now sent only when CPU, memory or disk usage is on course to reach 100% in less than 7 days. Webhooks receive it with the level forecast (it was warning). The weekly syslog report is still sent in English.
• Expiry, DNS change, domain change and traffic notifications are easier to act on. They now arrive in the language of the notification channel, which is the Default Language set under Settings → General unless the channel has its own, and list the facts one per line. An expiring domain shows its registrar, the expiry date in the System Timezone and the days left. An expiring certificate shows the host name, the origin IP and the DNS zone. A DNS zone changed outside AtlasEye shows each changed, added or removed record with its old and new value. A change in your GoDaddy account shows what changed on each domain, with nameserver, lock and transfer-protection changes first. A traffic drop or spike shows the hour checked, its page views and the usual figure, and for a drop, the time of a linked device outage or of a recent change to the linked DNS zone. Long lists show the first ten changes and the number of the others. Each notification ends with the steps to take. When they are sent is unchanged, but their subjects are worded differently, so update any mail or webhook filter that matched the old subjects.
• Alerts from the built-in monitoring rules say what to do. When one of AtlasEye's own alert rules fires, for example the API not responding, device monitoring stalling or the syslog collector dropping messages, the notification now says in plain words what is wrong, what it means and what to do, with the command to run, in the channel's language. FIRING banners and lists of internal labels are gone, and the alert for dropped syslog messages names the cause. When an alert ends, the message gives its start, its end and how long it lasted, and email and Telegram show it as a reply to the alert. Alerts from Settings → Alert Thresholds show the current value next to the threshold, for example "Currently 92.4%, above the threshold of 80%.", and the host or container that crossed it. Alert rules you added yourself keep their own title and description. For webhook channels, the level of an ended alert is now "resolved". On a server updated with Apply Update, the built-in alerts show their reading, and the dropped-messages alert its cause, from the following update on, which brings the new alert rules. Alerts from Alert Thresholds show their value right away.
• A new server installed from another channel takes its updates from that channel. A server installed with sudo bash atlaseye-install.sh --channel edge got its first build from that channel but then looked for updates on the stable channel. The installer now records the channel, so Settings → Updates offers the builds of the channel you installed from. A server installed that way earlier still looks on stable until you set UPDATE_CHANNEL=edge in its .env and recreate the api and updater containers.

• Component versions in the machine-readable inventory were wrong for five packages. Each AtlasEye service publishes the list of open-source components it ships, which auditors and vulnerability scanners read directly. Where two services shipped different versions of the same component, the inventory reported one version for both -- so a scanner was pointed at a version that service does not run. The list now reports each service's own versions, and a check compares it against the pinned dependency files on every build. No component changed; what changed is that the document now says what is actually installed.

• Two shipped components were held back from security updates by our own version limits. The updater — the component that installs every other update — was held to a web framework old enough to have seven published advisories against it, and the optional on-host Service Manager agent to a cryptography library with seven of its own. Neither was waiting on anything upstream; both fixes had been available for some time. Both now install current versions, and the dependency scan that should have surfaced this covers every component we ship rather than three of the six.

If you run the on-host agent, note that it now needs Python 3.9 or newer on the managed host. The installer checks and stops with a clear message before it changes anything, so an older host fails safely rather than half-way through. Ubuntu 20.04's default Python 3.8 is below that line.

• Every service image is now built from a verified dependency set. The images were previously assembled from version ranges, so the exact third-party code inside one depended on what the public package index served the day it was built — and a compromised or typosquatted release would have been accepted silently. Each service now builds from a locked list that names an exact version and a cryptographic checksum for every package it pulls in, directly or indirectly, and the build refuses anything that does not match. This does not change how AtlasEye behaves; it closes the last step in the chain from our source to your host that could not be checked. The update manifest was already signed and the images already pinned by digest, so what you receive can now be verified end to end.

No customer-facing changes in this release.

• A brand-new install no longer stalls with "opensearch is unhealthy". The installer started the whole stack before it prepared the search node's security configuration, so the services that wait for search to be ready never came up and the install stopped partway — with no way back except starting it again. The search node is now prepared — and given time to report itself ready — before the rest of the stack starts. Updates repair it the same way, air-gap and online alike: a host installed while this was broken is fixed by its next update instead of having that update rolled back.

• Installs and updates survive a dropped image download. A single truncated layer used to end a connected install outright, and the only way back was to download the installer again and start over. Image pulls now retry before giving up, on both the install and the Apply Update path.

• A failed download now tells you which registry to look at. Any pull failure used to blame your licence credential, even when the image came from a public registry that needs no credential at all — sending you to the portal when the real problem was your host's outbound network.

Changed

• The last two layers that were re-downloading on every update now stay put. The previous release stopped the large dependency layer from being fetched again each time. Two smaller layers inside the component that performs the update were still doing it — about 49 MB between them — because an unrelated step was giving them a new identity on every build. They now keep the same identity until their contents actually change. As before, your next update fetches them once and the ones after that skip them.

Fixed

• An update no longer reports failure when it could not replace the maintenance scripts on your server. Refreshing those scripts is the last step of an update, and it is meant to warn and move on — by that point the new version is already running and has passed its health check. On a server where the install directory is not writable by the account the product runs as, that step stopped the update instead, so the log ended in an error even though the upgrade itself had succeeded. It now names how many files it could not replace and what to change, and finishes normally.

Fixed

• The hardware fingerprint in Settings → Licensing is the one your licence is actually registered to. It used to be recalculated from the machine each time the page loaded. That reads the same for most installs, but after a container rebuild it can differ from the value your licence was activated with — so the one time you needed it, when check-in reports the licence is registered to a different machine, the page showed you the wrong string to send the vendor.

Changed

• Stable release — the 1.2 line is now on the stable channel. If you've been on 1.1.74, this brings everything since: a faster, more resilient data layer across the app; the in-app detailed changelog in Settings → Updates; and the new Topology tools — click an incident badge to jump to that device's incidents, multi-select + delete nodes, and a "bps" toggle that shows link bandwidth on the map. No breaking changes; upgrade from the Updates panel when you're ready.

Severity: minor

Added

• See link bandwidth on the network map. A new "bps" toggle on the topology toolbar overlays each link with its current throughput (↓ in ↑ out, e.g. ↓12.3M ↑2.0M) for devices monitored over SNMP/MikroTik. Off by default; refreshes every 30s while on. Links without bandwidth data simply show no label.

First Phase-7 published manifest (gray-cloud registry + HMAC auth + Ed25519 signed).