Infrastructure monitoring
Server monitoring that ties health, logs, and agents together
Track servers with agent-based installation, CPU, memory, disk, service state, health history, and warning signals from the same workspace.
Backed by app modules
- 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
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
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.
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.
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-monitoring
Frequently asked questions
See also: Guide: best server monitoring tools · Guide: network monitoring tools · Network telemetry hub · Website monitoring · Pricing
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.