Product proof
Already live in the product
Backed by app modules
Running in production today: server monitoring with server health logs for every monitored machine.
Protected app route:
/server-monitoringHow it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Agent installation flow
CPU, memory, disk, and health checks
Server health logs and warning history
Tenant-scoped server visibility
Workflow
What teams can do here
Step 1
Add a server
Step 2
Download/install the agent
Step 3
Monitor live status
Step 4
Review health logs when warnings appear
How it works
How it works
01
Register the server
Add a server with its name, hostname or IP and environment (production, staging, development or testing). Pick how it is onboarded: a bundled agent, SSH, or WinRM for Windows hosts. Tag servers into groups such as web, db or a named cluster so you can filter them later.
02
Install the agent and start ingesting
Each server gets a per-server enrolment token and stays in a pending enrolment state until its first successful agent check-in. Once the agent reports, it pushes system stats: CPU usage and core count, memory total and used, disk usage and running processes.
03
Track health, status and uptime
The Server Health Log is the source of truth for status and warning history. A scheduled uptime task records online and offline periods with their duration in the Server Uptime Log, so you keep a continuous record of when each server was up or down.
04
Alert on threshold breaches
A recurring resource task compares the latest CPU, memory and disk figures against per-server warning and critical thresholds. Breaches raise a Server Alert and are auto-resolved when usage returns to normal, so open alerts reflect the current state rather than stale noise.
05
Notify and escalate
Critical alerts trigger email and Slack notifications through per-organization notification settings, with a cooldown to prevent spam, and high or critical alerts open a support ticket automatically. Notifications are suppressed while a maintenance window is active.
Example
A worked example
Say a logistics company runs 45 servers across two data centres — order databases, WMS apps and a handful of staging boxes — enrolled with the agent and tagged into web, db and warehouse groups. One Friday the primary order database crosses its 80% disk warning threshold: an alert opens and lands in the health log. At 92% it goes critical — the on-call list is emailed, the ops Slack channel pings, and a NETWORK ticket opens automatically. The team archives old shipment logs; the next resource check auto-resolves the alert, and the uptime log keeps the whole timeline for Monday's review.
FAQ
Frequently asked questions
Do I have to use the agent, or can I monitor over SSH?
Both. A server records how it was onboarded: the bundled agent, SSH, or WinRM for Windows hosts. The agent path issues a per-server enrolment token and the server stays pending until its first check-in, after which stats flow automatically.
What does the agent actually collect from a server?
System stats are stored per sample: CPU usage and core count, current CPU frequency, total and used memory with a percentage, total and used disk with a percentage, and per-process CPU and memory. Those samples feed both the live status and the alert checks.
How are CPU, memory and disk alert thresholds decided?
Each server carries its own warning and critical thresholds for CPU, memory and disk, with sensible defaults you can tune. Warning breaches are logged; critical breaches also send notifications. When usage drops back under the line the matching alert is auto-resolved.
Can I silence alerts during planned maintenance?
Yes. A maintenance window for a server suppresses alert notifications while it is active, so a planned reboot or patch cycle does not page the team. Status and health events are still recorded; only the outbound notification is held back.
Do server alerts turn into tickets?
High and critical server alerts automatically open a support ticket in the NETWORK category, titled with the server name and the alert type, so the incident is tracked in the same helpdesk your team already uses instead of living only in an email.
Is one tenant able to see another tenant server data?
No. Every server, stat, health log and alert is scoped to the organization that owns it. Notification settings, recipients and webhooks are also per-organization, so each tenant keeps its own thresholds and its own alert routing.
Does Infronest monitor Windows servers as well as Linux?
Yes. Windows hosts can onboard over WinRM or with the agent, and Linux servers use the agent or SSH. Whichever path a server takes, its stats, health log, uptime history and alerts land in the same console.
How much does server monitoring cost?
Infronest is licensed per module, so you can start with server monitoring alone and add other modules later. Current rates are on the pricing page, and you can see it against your own fleet with a demo.
See also: Guide: best server monitoring tools · Guide: network monitoring tools · Network telemetry hub · Website monitoring · Pricing
Related
Explore connected offerings
Know a server is in trouble before your users do
Enrol the fleet with the agent, SSH or WinRM, tune per-server thresholds, and let alerts, Slack pings and auto-opened tickets carry the on-call weight.