Salix Monitor 360 product update: tighter user scope, calmer alerts and smarter agents

User pages are now locked down properly

A major part of this week’s work was reviewing the normal user area of the application.

In Salix Monitor 360, there is an important difference between a normal user and an organisation administrator. An organisation admin may need to see data across an organisation and in some cases across linked child organisations. A normal user should not.

That sounds obvious, but once multi-organisation features start growing, it becomes very easy for useful admin-level scope logic to creep into places where it does not belong. This week, the user menu pages were checked carefully to make sure normal users only see their own data.

That included the user dashboard, monitors, alerts, agents, network view, reports, posture pages, vulnerability reports, profile page and help section.

The dashboard and network pages were the most important fixes. They were reviewed and tightened so a normal user cannot accidentally see organisation-wide totals, monitors, agents, incidents or report data. That is the sort of boundary that has to be boringly correct.

That separation matters. Monitoring systems can contain sensitive operational information and the app should never casually leak that information across account boundaries.

The user dashboard is becoming more useful

The user dashboard also had some practical work done.

The dashboard should not just be a pile of numbers. It should be a useful overview that helps someone understand what needs attention and where to go next.

The open incidents area has been improved so, when incidents exist, the dashboard can show useful incident details rather than just a vague count. The goal is for the dashboard to answer sensible questions quickly:

• What is open?
• Which monitor is affected?
• How serious is it?
• When did it start?
• Where do I click to investigate?

The dashboard also now aims to link into the rest of the user area in context, without turning itself into a duplicate menu. Links belong where they help: from an incident to alerts, from a monitor summary to monitors, from a report summary to reports and so on.

Alerts are being made calmer and more useful

A lot of time this week went into alerts.

Alerting is one of those areas where “technically working” is nowhere near good enough. A bad alert system can be worse than no alert system, because it trains people to ignore it.

The alert flow has been tightened in a few important ways.

First, repeat behaviour has been clarified. A rule with repeat reminders set to zero should send the initial alert and then stay quiet until the incident recovers or closes. It should not keep sending the same warning every few minutes like a toaster with anxiety.

That behaviour has been hardened so “initial only” really means initial only.

Second, alert messages are being made more useful. An alert should explain the problem, not just announce that a problem exists. For agent-backed monitors, that means giving enough context for someone to understand whether the issue is the monitored service, the machine, or the freshness of the agent data.

For example, if a CPU monitor fails because the agent is stale, the alert should say that clearly. It should not imply the CPU is high when the real issue is that the machine has stopped sending fresh data.

That distinction matters. “CPU is critical” and “agent has not checked in recently” are completely different problems.

The alert delivery work has also been reviewed so different notification channels can carry clearer, more consistent context. The aim is simple: every notification should contain enough information to help someone take the next step.

Agent monitoring has been made more reliable

The Linux and Windows agents had a fairly serious workout this week.

The focus was reliability: agent check-ins should update the product clearly, freshness should be trustworthy, and agent-backed monitors should not report success unless the application has genuinely accepted the latest data.

The public lesson is simple. A monitoring agent is only useful when the main product can trust the information it receives from it.

Smarter agent telemetry, less noise

Agent data is one of the most important parts of Salix Monitor 360, but it has to be treated carefully.

The agent work has been tuned so frequent health signals stay quick and useful, while heavier background information does not create unnecessary noise. The goal is not to collect less useful information. The goal is to collect it at the right rhythm.

Windows agents need proper scheduled tasks

A useful discovery this week came from testing the Windows agent on Windows 11.

Running the agent directly in PowerShell is useful for testing:

PowerShell -ExecutionPolicy Bypass -File C:\salix-agent.ps1

However, it is not reliable enough for live monitoring.

On Windows 10 and Windows 11, an open PowerShell window can appear to be sitting there happily while the desktop session is locked, the screen turns off, power saving kicks in, or the machine throttles interactive work. The window may still show recent HTTP 200 messages, but that does not guarantee the agent is actively sending fresh check-ins at that moment.

That can make a Windows monitor look stale even though the user thinks the agent is still running.

The /agents page and help documentation have been updated to make this clearer. PowerShell is for testing. Reliable Windows monitoring should use a Scheduled Task.

That should save a lot of future head-scratching.

Monitor pages have had a polish pass

The monitor pages have also had more user-facing polish.

The aim is to make monitor cards easier to read, especially on smaller screens. Status information, last check times, alert state and agent-backed monitor details need to be clear without making the user decode a wall of technical output.

Agent-backed monitors now behave more naturally, with clearer stale handling, fresher updates when agents check in and better separation between an actual metric problem and an agent freshness problem.

This is one of those areas where tiny wording details matter. A monitor saying “critical” is not enough. It needs to say whether the CPU is actually high, the agent is stale, the endpoint timed out, or the latest result is missing.

A monitoring platform should reduce ambiguity, not create it.

Help documentation has been updated

Both normal user help and organisation admin help have been updated.

The normal user help now better explains the pages available from the user menu, including dashboard, monitors, alerts, agents, network, reports, posture, vulnerability reports and profile settings.

The organisation admin help has also been brought up to speed. It now explains more clearly how organisation admin scope differs from normal user scope, how linked child organisations fit into the picture, how alerts and incidents behave and how agent-backed monitoring should be understood.

This is not glamorous work, but it matters. A product with powerful features still feels unfinished if the help pages are vague, stale or written for a version of the app that no longer exists.

The goal is that a normal user, organisation admin or super admin can open the relevant help page and see guidance that matches the app they are actually using.

Public website and sales pages have also been tidied

Alongside the app itself, the public website has had a clean-up and consistency pass.

Several public pages have been tightened so the layout, calls to action, button styling and product explanations feel more consistent. The public-facing copy has also been refined around organisation branding, agents, dashboards and signup guidance.

This is part of getting the product ready as a whole. The application can be technically strong, but the public website still needs to explain it clearly and professionally.

A product does not only live in the code. It lives in the first impression too.

Why this week mattered

This week was not about adding one shiny headline feature. It was about making a lot of connected parts behave correctly together.

• User scope affects dashboards, reports, network views and alerts.
• Agent freshness affects monitor status, incidents, notification content and user trust.
• Alert repeat behaviour affects whether the platform feels calm or annoying.
• Documentation affects whether users understand what the system is telling them.
• Agent telemetry rhythm affects whether the system stays useful when many agents are running in the real world.

These are not separate concerns. They all feed into whether Salix Monitor 360 feels reliable.

The product is now closer to the kind of monitoring system I want it to be: clear, scoped properly, less noisy, more helpful and better prepared for real users.

This has not been about adding a big shiny feature. It has been about making the existing app safer, clearer and harder to misuse. In a monitoring system, that matters just as much as the headline functionality.

Super admin views now have better organisation scope

The super admin dashboard can now be viewed across all organisations or filtered down to a selected organisation.

The same organisation-scope idea has been applied to other super admin areas, including the agents overview and global alerts pages. Logs and jobs were also checked so their existing filters behave properly.

The goal is straightforward: when a super admin chooses an organisation, the numbers, tables and graphs should follow that choice. A selected-organisation view should not quietly show whole-app totals in the background.

Operational history is now clearer and safer

Operational history needs sensible housekeeping so the product remains responsive and understandable over time.

The relevant history screens now explain when older raw history may no longer be available, so users do not have to guess why an older date range is empty.

The public point is that Salix Monitor 360 is being designed to keep useful evidence without letting background history grow unchecked forever.

Global appearance controls have been tidied

Older global appearance controls have been tightened.

The aim is to keep organisation branding where users expect it: in the organisation branding area, rather than spread across older global controls.

This reduces the risk of broad appearance settings affecting the wrong part of the product.

Organisation appearance now belongs where it should: in the organisation branding area, where org owners and admins can control supported branding and styling for their own organisation.

Admin settings and page headers have been polished

The higher-level admin settings page has had a layout tidy-up so the cards are grouped more clearly and the section headings are easier to read.

The admin help page, security page, user reports page and vulnerability reports page have also been brought into line with the newer Salix Monitor 360 header style used across the rest of the app.

These are small visual changes, but they help the app feel less like a collection of older pages and more like one consistent product.

Less room for accidents

A lot of this update is really about removing traps.

• Super admins can inspect one organisation without accidentally reading whole-system figures.
• Operational history now has a clear retention window instead of growing forever.
• Older appearance controls have been tidied so organisation branding remains clearer.
• History and report screens now explain data availability more clearly.
• Older-looking pages have been pulled into the same visual language as the rest of the app.

It is the sort of work that makes the platform feel safer day by day: fewer surprises, fewer ambiguous controls and fewer places for bugs to hide.

Final thought

Good monitoring software should be calm, clear and difficult to misunderstand.

It should separate users properly, show the right scope at the right time, explain its limits honestly and avoid global controls that can quietly spill into the wrong part of the app.

That has been the wider theme of this round of work: cleaner boundaries, less noise, safer admin tools and better information for the people using the system.

Salix Monitor 360 still has more testing and polishing ahead, but these changes move it closer to the kind of monitoring product it needs to become: practical, steady and less likely to bite later.