Is it safe to run on a production server?
Is it safe to run on a production server?
Yes. The agent only reads local metrics and its own auth logs, and connects outbound over TLS. It opens no inbound ports and has no offensive capability.
A lightweight agent streams metrics and security signals over mutual TLS. Servers Sentinel scores each host, alerts the channels you already use, and flags brute-force activity the moment it starts.
First server free. No card, install in one line.
Built for mixed Windows and Linux fleets
By the time a dashboard refreshes, the incident is already an hour old. Servers Sentinel closes that gap.
A host stops reporting and nobody notices until a user does. Coverage should not depend on someone watching a screen.
Every tool has its own inbox. Signals scatter across email, chat and webhooks until they are all ignored.
RDP and SSH password-guessing runs for hours before it shows up in a log review. It should surface in seconds.
Thresholds set per server rot out of sync. One default should cascade, with per-host overrides on top.
Servers Sentinel collects metrics locally, streams them over mutual TLS, and turns them into a single health score and a clear alert. Global config templates cascade to every server; any host can override a key without breaking the default.
No agents to compile, no ports to open inbound. Everything runs outbound over TLS.
Register a host in the panel and get a one-line install command with a short-lived enrollment token.
The script detects OS and architecture, installs the agent as a service, and enrolls it over mTLS.
CPU, memory, disk and network stream in on a schedule. Each host gets a live health score.
Rules fire to email, Telegram, Slack or a webhook. Brute-force is detected on the agent and flagged instantly.
The core loop today, with security, disks and databases designed in as pluggable modules.
CPU, memory, disk and network per host, stored as time series and drawn as sparklines you can read at a glance.
Global templates set the defaults; each server overrides only the keys it needs. Overrides cascade, they never fork.
Every agent holds a client certificate. Ingest is mutually authenticated, so a leaked token alone opens nothing.
The agent watches RDP and SSH auth locally and reports an active attack with the top source IPs.
Each host is reduced to a single 0-100 score, so a fleet of hundreds sorts itself by what needs attention.
Email, Telegram, Slack and webhooks. Add a channel, send a test, and route rules to it.
Users, teams and roles (viewer, operator, admin) keep each customer's fleet isolated behind one login.
One protocol for a systemd unit on Linux and a Windows Service, on amd64, arm64 and 386.
Start free on one server. Pay by host count, monthly or yearly.
Sign up and watch your whole fleet: metric history, uptime and API checks, Telegram alerts and reports. When the trial ends nothing is charged - the account returns to Free and single-server monitoring keeps running.
Fifteen situations in which not knowing what a server is doing stops being an acceptable risk. If you recognise your own estate in any of them, the gap is already there - it just has not cost you anything yet.
The first group is about what goes unseen. None of these situations involve negligence: they are what happens when the number of machines grows past the number a person can keep in their head, which for most teams is about four.
A machine stops reporting. It may have been rebooted by a hypervisor, lost its route, run out of memory, or simply been powered off by someone tidying a rack. Nothing announces this - an absent server produces no error, and silence is exactly what a healthy one produces too.
The gap between the failure and the phone call is the whole problem. It is usually measured in hours, it is always discovered by the worst possible person, and by then the question is no longer what broke but why nobody knew.
Disk exhaustion is the most predictable outage there is. Logs grow, a backup is written twice, a temporary table is never cleaned up, and the free space curve has been pointing at the same day for a fortnight.
It is also the outage that costs the most to recover from, because a database that runs out of space mid-write does not stop politely. The difference between a warning at 80% and a page at 100% is the difference between a two-minute cleanup and a restore from last night's backup.
Memory leaks, connection-pool exhaustion, a queue that drains slower each day, a certificate a month from expiry - none of these are events. They are slopes, and a slope is invisible to anyone who only ever looks at the current value.
Without a history there is nothing to compare against. 'Is 70% memory normal for this host?' has no answer unless something recorded what normal was, and that recording has to have been happening before anyone thought to ask.
Most real estates are mixed: a couple of Windows servers for the accounting system and the file share, a handful of Linux machines for the site and the database, perhaps something ARM at a remote site. Each platform has its own native tooling and none of them talk to each other.
So the picture is assembled by hand, in the head of whoever is on shift, out of a services console, an SSH session and a hosting-provider panel. That assembly happens only when someone goes looking - which is to say, after something has already gone wrong.
A server in the office, two at a hosting provider, three in one cloud, one in another because of a migration nobody finished, and a box in a branch that was set up before the current team arrived. Each has its own address space, its own access route and its own owner.
There is no single console that spans them, because they were never bought as one thing. What is needed is one place that treats them as one estate regardless of where each of them physically sits.
The second group is about the distance between something being detectable and somebody actually acting on it. Most incidents that hurt were visible in a log the whole time; the failure was in the last few metres, between the machine and a human being.
One system mails, another posts to a chat channel, a third fires a webhook, the hosting provider sends SMS, and the backup software writes a report that lands in a folder nobody has opened since it was set up.
Nothing correlates. The same incident produces four notifications with four different names, in four places, and the work of realising they are the same incident falls to whoever happens to be looking at the right window.
A monitoring setup that has not been tuned produces alerts continuously - a CPU spike during a nightly job, a disk crossing a threshold it crosses every week, a service that restarts as designed. People learn very quickly that these can be ignored, and they are right until the day they are not.
Once a channel has trained its readers to skip it, adding more alerts makes things worse rather than better. The useful measure is not how much is detected; it is how much reaches somebody who then does something.
Small and mid-sized teams do not run a rota. The person who knows the systems is asleep, on a plane, or on holiday, and the incident does not care. Everything therefore has to be understandable by whoever is actually available - including someone who did not build any of it.
That puts a hard requirement on what an alert has to say. 'db-01 CPU 96%' means nothing at 3am to a person who has never logged into db-01; what it happened alongside, and what normal looks like, is what makes the difference between a fix and a phone tree.
Every server was configured by hand, at a different time, by a different person, with a different idea of what warranted waking someone up. Two years later no two machines agree, nobody remembers why one is set to 85% and another to 95%, and changing them all means visiting them all.
What an estate needs instead is one default that cascades everywhere, and per-host overrides that are visible as overrides - so a deviation is a deliberate decision somebody can review, rather than an accident of history.
An exposed RDP or SSH port is under attack continuously, and a successful guess looks, in the log, almost exactly like a normal login. The evidence is there - a rise in failures, an unfamiliar source, a first-ever successful login from a new country - but only as lines in a file nobody reads daily.
Detection therefore has to be something the machine does, not something a person does once a quarter. The window that matters is the one between the first attempt and the first success, and it is usually measured in hours.
The third group is about the moment somebody outside the technical team needs an answer. Availability, incident history and evidence of supervision are all things that either exist as a record or do not exist at all - they cannot be reconstructed after the fact from memory.
Once availability is written into an agreement it stops being a feeling and becomes a number that has to be produced monthly, defended if disputed, and calculated the same way every time. 'It was up as far as we know' is not a measurement.
The record also protects you in the other direction. Most availability disputes are about whose fault an outage was, and a timeline showing that the host was healthy while the customer's own uplink was down ends the conversation faster than any argument.
Cyber-insurance applications, supplier security reviews and regulatory regimes for payment and personal data all ask a version of the same question: how do you know your systems are running as intended, and how would you know if they were not.
What is wanted is not a tool name. It is evidence that supervision was continuous over the period under review, that alerts went somewhere a person read, and that incidents were recorded rather than remembered.
Managed service providers, freelance system administrators and small IT firms carry dozens of machines across different companies, providers and network layouts. Each client has its own hours, its own tolerance for downtime and its own idea of what counts as urgent.
Configuring each one by hand does not scale, and neither does discovering a problem only when a client telephones. Such an estate needs one baseline applied everywhere, per-client exceptions where a client genuinely differs, and a single wall where all of them can be seen at once.
Which machine matters, what normal load looks like on it, which alert is safe to ignore, why that threshold was raised in March - none of this is written down anywhere. It is carried by the person who set it all up, and it leaves when they do.
A handover then becomes an archaeology project, and the first months under new hands are spent rediscovering things that were known perfectly well a year earlier. History and configuration that live outside a person are the only defence against that.
Supervision is not free of risk. Anything that reads metrics from every machine you own has, by definition, a foothold on every machine you own - and it is reachable from outside, because that is the point of it.
So the question of how the fleet is watched is also a question about that channel: who can talk to it, what identity each side proves, what happens to the data in transit, and whether a compromised console would hand over the estate. It is a fair question to ask before anything is installed anywhere.
Yes. The agent only reads local metrics and its own auth logs, and connects outbound over TLS. It opens no inbound ports and has no offensive capability.
Yes. One protocol drives a systemd unit on Linux and a Windows Service, on amd64, arm64 and 386. The installer detects the platform for you.
Every agent enrolls with a client certificate and streams over mutual TLS. A stolen enrollment token is short-lived and cannot impersonate an already-enrolled host.
You set global templates once. Each server can override individual keys; overrides cascade on top of the defaults instead of replacing them, so a template change still reaches every host.
Yes. The panel ships as a docker-compose stack behind Traefik with Postgres (TimescaleDB optional). See the deploy guide in the repository.
The agent watches RDP and SSH authentication locally, so it flags an active password-guessing attack and its top source IPs in seconds, even before the panel refreshes.
With Servers Sentinel I install the agent as a systemd-unit or Windows service, connect it with an mTLS outbound channel and see the latest telemetry and host health score. I set a rule for missing data, send a notification to mail, Telegram, Slack or webhook and check the test gap; I can keep one server on a free plan with email notifications.
As a free alternative to Servers Sentinel, I run blackbox_exporter/Prometheus or a ping/TCP cron check from another site, store last_seen and send an alert via Alertmanager. I separately check the monitoring itself with an external dead-man switch, set the delay for a normal reboot and document the owner of the host; otherwise, the loss of the monitoring system appears as a green state.
With Servers Sentinel, I collect the used and free space of each filesystem as a time series, set a general threshold and a separate override for a specific volume, and send a notification before the critical value. I look at the growth rate next to the current percentage, check the inode on Linux and leave enough margin for WAL/log and emergency operation.
For free, I install node_exporter/windows_exporter with Prometheus and Alertmanager or run df/Get-Volume via cron/Task Scheduler. I warn by percentage and absolute gigabytes at the same time, add rate/predict_linear for a 24–72 hour horizon, configure logrotate/retention and test the alert by artificially filling a non-critical volume.
With Servers Sentinel I store a series of CPU, memory, disk and network, compare the host to its own history and roll up the current state into a 0-100 score. I set the duration of the condition so as not to react to a minute peak, and create separate uptime/TLS/API checks where the certificate duration or application response is important.
I deploy Prometheus, exporters and Grafana for free, set recording rules for baseline and alerts for sustainable growth, and check certificates with blackbox_exporter. I store at least a few weeks of data, mark deployment/maintenance on the graphs, and use rate/deriv only for relevant metrics; I support TSDB and rules myself.
With Servers Sentinel I use one protocol for Windows service and systemd agent on amd64, arm64 and 386, get the same base metrics and same health score. I keep the platform differences in the overrides, but sort the entire fleet by risk and pass the telemetry out to mTLS without opening the agent's inbound port.
For free, I combine windows_exporter and node_exporter in one Prometheus, normalize host/client/os labels and build a common Grafana dashboard. I map Windows Event Forwarding and syslog/Loki by UTC, describe the different thresholds for the OS as code, and check that updating the exporter does not change the names of the metrics without migrating the rules.
With Servers Sentinel I install an agent on each host; it initiates the outgoing connection itself and is authenticated by the mTLS client certificate. I assign site and owner tags, see all hosts in one console, and set rules globally with point-by-point overrides, without building an incoming route to each machine.
For free, I connect WireGuard sites and poll exporters with central Prometheus or use remote_write/agents that send metrics externally. I limit the ACL to the collector address only, protect with TLS certificates, buffer data when broken, and monitor the VPN itself; I do the network design and key rotation myself.
With Servers Sentinel I create email, Telegram, Slack or webhook channels in one console, send a test and send rules to them according to the required hosts. I use single names and host context so that the operator sees the metric, threshold and time, rather than collecting an incident from four independent letters.
For free, I route Prometheus Alertmanager to one notification gateway, set group_by, group_wait, repeat_interval and inhibition, and leave the sources a link to one runbook. I normalize labels severity/service/owner and check routes with test alerts; SMS and external providers may still be charged even with free software.
With Servers Sentinel, I set global thresholds, condition durations, and point exceptions for hosts where the norm is different, and then route severity levels to different channels. I use the health score to prioritize, test the rule, and review alerts that haven't been acted on.
For free, I maintain a catalog of alerts with an owner and a runbook, use for in Prometheus, grouping and inhibition in Alertmanager, and close scheduled work with silence with automatic completion. I measure the number of notifications, acknowledgments and retries, remove non-actionable signals and do not mask the noise by simply raising all thresholds.
With Servers Sentinel I separate severity and channels, append a role/client to the hostname, and only configure the rule after a persistent violation. I check the message with a test, leave a link to the runbook in the recipient webhook and use a metric graph/health assessment so that the person on duty can distinguish a one-time peak from degradation.
For free, I build an Alertmanager routing schedule, send critical events to a call/chat through an available gateway, and the rest to the daily queue. I write a runbook of three actions, an owner and an escalation criterion, add a dashboard link and regularly issue training alerts; The free call channel depends on the selected service.
With Servers Sentinel I specify a global configuration template, and on a specific server I override only the desired key; the override cascades on top of the default rather than copying the entire config. I see the deviation as an exception, change the overall threshold once and check which hosts deliberately stayed at a different value.
For free, I store Prometheus rules and inventory parameters in Git, generate Jsonnet/Ansible rules and require a review with the reason and deadline for the exception. I run a CI syntax check, a diff of the deployed configuration, and a report on overrides; without such discipline, even a free stack quickly reverts to manual drift.
With Servers Sentinel I enable local authentication detection: an agent on Windows or Linux reads RDP/SSH events and transmits an active attack with a top IP source. I route the rule to the live channel and match one source between hosts; The detection feature is available on an eligible paid or trial plan.
For free I collect Windows 4625 and sshd Failed password in Wazuh/Elastic or Loki, create a correlation by source_ip for a sliding window and an alert for the subsequent successful 4624/Accepted. I synchronize time via NTP, normalize IPv4/IPv6 and exclude test scanners; the free path requires a separate collector and rules support.
With Servers Sentinel I create TCP/TLS/API checks from an external point, store a history of results and separate application unavailability from missing agent telemetry. I set an SLO, record maintenance and generate a periodic report with time limits; Before signing, I agree with the customer on the interval, inspection regions and exclusion rules.
For free, I deploy blackbox_exporter and Prometheus outside the controlled site, consider availability as successful probes/expected probes and store Alertmanager events. I note maintenance in a separate log, synchronize UTC and generate a Grafana report; one verification point does not prove global availability, so if necessary I add an independent probe.
With Servers Sentinel I save the history of metrics, uptime checks, rule settings, channels and events, and use the audit log for owner and policy changes on the appropriate plan. I upload a report for the exact period, attach a delivery test and explain the mTLS identity of the agents; I note the absence of data as a gap in observation, and not as the norm.
For free, I store Prometheus/Loki/Wazuh on a secure server with backup, configuration and approvals in Git, and incidents in a ticket system. I monthly record coverage, gaps, alert test and list of exceptions, sign the report and limit access; the instrument itself, without a closure procedure, is not evidence of control.
With Servers Sentinel I split the fleet by team/tenant, assign viewer, operator and admin roles and apply basic templates with client exceptions. I sort all hosts by health score, send notifications to the owner, and use the Business/self-hosted option where isolation and unlimited fleet are needed.
For free, I deploy separate Prometheus tenancies/instances or isolate data with strict labels and ACLs in Grafana, storing client secrets in different vaults. I generate a configuration from inventory, route Alertmanager by tenant/owner and test blocking cross-access; secure multi-tenancy requires more work than one shared dashboard.
With Servers Sentinel I sign hosts by role and owner, store metrics series, global templates and explicit overrides, and associate channels with owners. I use the history as a baseline, document the reason for the non-standard threshold next to the change process, and give the new operator a view-only role before transferring authority.
For free, I maintain inventory and runbooks in Git, add dashboard links, owner, dependencies and rationale for each override, and accept changes via pull request. I store Grafana/Prometheus provisioning as code, mark deploy/maintenance and transfer the incident to another employee once a quarter; Without organizational practice, graphics themselves will not retain knowledge.
With Servers Sentinel I use mutual TLS outbound connection: each agent receives a client certificate, and the short-lived connection token does not replace the identity already issued. I check the service rights, the list of collected metrics and logs, disable unnecessary actions, deploy the pilot on one host and control the revocation of the certificate when the server is deleted.
For free, I install node_exporter/windows_exporter under a separate unprivileged account, listen only to localhost/VPN and limit the collector set. I protect scrape with TLS/mTLS or network ACLs, sign packets, commit versions, scan for updates, and don't enable textfile scripts that write from untrusted sources; I separate configuration management from monitoring.
Three questions worth answering before you install anything with administrative rights across a production fleet.
Servers Sentinel is written by Victor G. Bobrov, lead server security specialist at Recovery Toolbox, with 20+ years in systems and security engineering and Microsoft MCSD/MCDBA certifications. The health scoring, the alert rules and the documentation on this site are his work, published under his name rather than an anonymous brand. Documentation →
The vendor is File Master LLC, a company registered in Bulgaria (EU) - Bulstat/VAT 180842207, office in Varna, reachable by phone and email. Payments are handled by PayPro Global as merchant of record; the terms, the privacy policy and the data-processing agreement are published in full, not summarised. Terms of Service · Privacy · DPA
The agent reads local metrics and its own host's authentication log and streams them outbound over mutual TLS. It opens no inbound port and has no remote-command channel: nothing in it can be told from outside to run something on your server. Every agent enrolls with a client certificate, and an enrollment token is short-lived - a stolen one cannot impersonate a host that is already enrolled. The panel itself ships as a docker-compose stack you can run on your own hardware. Install the agent →
Fleet monitoring is not a subject of its own - it sits between the platforms it watches, the tools that came before it, and the standards a server is measured against. These are the sources that define each of them.
Links open on the sources themselves - Wikidata where the entity has an ID, the primary source where it does not.
Contact details for Recovery Toolbox and File Master LLC, plus the profile of Victor G. Bobrov, the company's lead security specialist.
File Master LLC is the legal entity behind the Recovery Toolbox online services and software products.
File Master LLC develops and supports Recovery Toolbox online services and software products for repairing damaged files, databases and mail storage formats. The company focuses on practical recovery tools for users, IT specialists and businesses that need to restore access to corrupted data.
Comments and suggestions are welcome. Please send website feedback by email: webmaster@recoverytoolbox.com

Server security specialist · 20+ years in systems and security engineering
Victor G. Bobrov leads security engineering at File Master LLC / Recovery Toolbox. He designs what Servers Sentinel watches for on a fleet: the health score behind a host's metrics, brute-force activity in its authentication logs, CIS-style configuration drift, and the alerting that has to fire before an administrator notices anything is wrong.
Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.
Add a host, run one line, and watch it report within a minute. The first server is free.