website issue monitoring
Web server monitoring. Host health beside website failures.
Track CPU, memory, disk and processes on Linux or macOS, then compare them with the public websites that depend on the host. See what is failing without assuming a green CPU graph means a healthy website.
Server monitoring requires a paid plan. Linux and macOS agent; no Windows agent.
definition
What Is Web Server Health Monitoring?
Web server health monitoring checks whether the host has enough CPU, memory, disk, and network capacity to serve its public websites. Visual Sentinel uses a lightweight Linux and macOS Bash agent that reports every 60 seconds over HTTPS. It records CPU usage, memory and swap where available, root-disk capacity, network counters, load averages, uptime, process count, and the top CPU-consuming processes supported by the host. You can set CPU, memory, and disk thresholds and route resulting alerts through the channels available on your paid plan. Server metric history is retained for 14 days on Solo and Starter, 30 days on Business, and 90 days on Agency. Linking a server to its public website monitors puts host evidence and customer-facing incidents in one dashboard, but it does not replace application tracing or service-specific telemetry.
what you get
Built for issues customers actually notice.
CPU, Memory, Disk & Network
Track CPU usage, memory and swap where available, root-disk capacity, and network counters on a 60-second reporting schedule.
Threshold-Based Alerts
Set custom thresholds for CPU, memory, and disk usage. When any metric breaches your limit, get alerted via email, Slack, Discord, Telegram, WhatsApp, or webhooks.
One-Command Agent Install
Install the Bash monitoring agent with a single curl command on supported Linux or macOS hosts. Bash, curl, jq, cron, and standard system tools are required.
Process Monitoring
See the top 10 processes by CPU usage, including the reported memory percentage and user, as investigation context.
Server + Website Evidence
Review supported host metrics beside uptime, SSL, DNS, performance, visual, and content checks without claiming to replace logs or application traces.
Plan-Based Historical Charts
Review retained server history for 14 days on Solo and Starter, 30 days on Business, or 90 days on Agency.
From a failed website check to a useful next step.
- Confirm the public failure. Compare the exact URL, HTTP status and available regions. A 403 can be an access rule; a failed regional check does not establish a global outage. Run a fresh website status check.
- Match the time, not just the latest graph. Check that the agent is still reporting, then inspect CPU, memory, disk and processes near the incident. A stale healthy sample is not a current health verdict.
- Separate host pressure from service failure. Several linked websites returning 502, 503 or 504 can share a web-service or upstream problem even while host metrics look normal. Confirm with proxy, application and provider logs. Visual Sentinel does not collect those logs or prove the cause from correlation alone.
- Verify each website after the repair. A recovered server does not prove every dependent website recovered. Confirm fresh successful website checks and inspect the rendered page when appearance was affected.
This is an investigation checklist, not a live incident report. Keep your existing application tracing and logging tools where you need those signals.
Connect server pressure to the website incident.
Server metrics matter most when they explain what users saw. These guides cover traffic spikes, Linux updates, security changes, and the monitoring architecture that keeps alerts useful.
A green server does not prove the website works.
A useful web server monitoring setup keeps host pressure, the public customer path, and application internals separate. That prevents a normal CPU graph from closing an incident while DNS, TLS, a dependency, or the rendered page is still failing.
| Layer | Signals to inspect | Visual Sentinel coverage |
|---|---|---|
| 1. Host health | CPU, memory, swap, root disk, load, network counters, uptime, and processes | Collected every 60 seconds by the supported Linux or macOS agent |
| 2. Public website path | HTTP status, response time, TLS, DNS, visible content, and rendered layout | Independent public checks linked to the server and customer-facing incident |
| 3. Application internals | Traces, centralized logs, JVM or IIS counters, database waits, and private service metrics | Not collected. Keep a service-specific telemetry product for this layer. |
Apache, Tomcat, IIS, and SQL Server monitoring
Visual Sentinel combines supported Linux or macOS host metrics with checks against the public endpoints those services expose. It does not collect application traces, database internals, JMX, IIS counters, or private localhost metrics, so use a service-specific telemetry product when those signals are required.
Apache web server monitoring
Apache failures can include worker-pool exhaustion, slow upstreams, and module errors that return 5xx responses. On a supported Linux or macOS host, Visual Sentinel can place CPU, memory, load, and public endpoint evidence in the same incident view when retained data is available.
The agent does not collect Apache busy-worker counts, requests per second, or scoreboard state, and Visual Sentinel does not fetch localhost or private-network pages. Keep mod_status private and use an Apache-aware metrics platform for those internals. Visual Sentinel can independently monitor the public URLs Apache serves.
Apache Tomcat monitoring
Tomcat sits between the JVM and the application. The common Tomcat failure modes are heap exhaustion (full GC stalls), thread-pool saturation under burst load, and slow JDBC pool exhaustion when a downstream database stalls. Host-level metrics catch the symptoms (high CPU during full GC, memory pressure on heap-bound workloads); the website-layer checks confirm whether requests still get through.
The agent does not collect JMX, Tomcat thread-pool depth, JVM heap, or garbage-collection pause metrics. Keep JMX and private Actuator endpoints on a private network and use a JVM-aware telemetry product for them. Visual Sentinel can pair supported host evidence with checks against the public URLs Tomcat serves.
IIS (Windows) monitoring
IIS failures can include application-pool recycles, request-queue saturation, and 503 responses during worker restarts. Visual Sentinel does not currently ship a Windows or PowerShell host agent. It can monitor the public HTTP or HTTPS URLs served by IIS, including configured status and body assertions.
Use a Windows-aware infrastructure product for IIS counters such as current connections, app-pool queues, and requests per second. Visual Sentinel's role is the external customer path: scheduled uptime, TLS, request-timing, and eligible visual or configured content evidence for public IIS URLs.
SQL Server monitoring
SQL Server failures can involve tempdb pressure, blocking, plan regressions, or replica lag. Visual Sentinel does not query SQL Server, collect wait statistics, or report disk queue depth. On SQL Server for Linux, its host agent can provide general CPU, memory, load, root-disk capacity, and network context; no Windows agent is currently shipped.
Use a database-aware monitoring product for active connections, blocked sessions, wait statistics, and replica lag. Do not expose database internals publicly for Visual Sentinel. Instead, monitor the public application endpoints that depend on the database and review their failures beside any supported host evidence.
how it works
Three steps, no extensions.
Add Your Server
Enter your server name, hostname, and operating system. Visual Sentinel generates a unique agent token for secure communication.
Run the Install Script
Copy the one-line curl command and run it on a supported Linux or macOS server with sudo. After installation, the agent reports metrics every minute via cron.
Set Thresholds & Get Alerts
Configure CPU, memory, and disk thresholds and choose the supported notification channels. A breach observed in a reported sample can trigger the alert workflow.
Frequently asked questions
What are server monitoring tools?
Server monitoring tools are software that continuously tracks the health and performance of your servers. They collect metrics like CPU usage, memory consumption, disk space, network traffic, and running processes, then alert you when something goes wrong. Visual Sentinel installs a lightweight bash agent on your server that reports these metrics every 60 seconds.
What are the best server monitoring tools?
The right server monitoring tool depends on whether you need host metrics, application traces, logs, service checks, or all four. Visual Sentinel is a focused fit for 60-second host metrics linked to public website incidents. It does not replace an application-performance or log platform.
What should web server health monitoring include?
Useful web server health monitoring separates three layers: host resources such as CPU, memory, disk, load, and processes; the public path such as HTTP, TLS, DNS, response time, and rendered-page evidence; and application internals such as traces, logs, JVM metrics, or database waits. Visual Sentinel covers supported host metrics and public website checks. It does not collect application traces, centralized logs, JMX, or database internals.
Can I monitor remote servers?
Yes. The Linux or macOS agent runs on the host and reports metrics over outbound HTTPS. Bash, curl, jq, cron, and supported system utilities are required. Root access is recommended for installation and broader process visibility, but the installer also has a user-mode path with reduced permissions.
Which operating systems does the server agent support?
The downloadable Visual Sentinel Bash agent currently supports Linux and macOS. It uses /proc and standard utilities on Linux, and sysctl, vm_stat, and other macOS system tools on macOS. Windows and FreeBSD agents are not currently shipped.
What server metrics does Visual Sentinel track?
Visual Sentinel tracks CPU usage, memory and swap where available, root-disk capacity, network counters, 1, 5, and 15 minute load averages, server uptime, process count, and supported top-CPU-process evidence. History is retained for 14 days on Solo and Starter, 30 days on Business, and 90 days on Agency.
Do I need separate server and website monitoring?
Visual Sentinel can keep supported host metrics and public website monitors in one dashboard and use the same plan-specific alert channels. You still need a dedicated tool when the job requires application traces, centralized logs, database internals, or private service discovery.
Can teams outside the US use server monitoring?
Yes. The server agent sends host metrics over outbound HTTPS, so teams in Australia, the UK, India, Europe, and other regions can use the same dashboard. Public website checks currently use the enabled EU and US regions; test your target host and alert routes during evaluation before choosing a plan.
Can I monitor shared hosting without installing an agent?
Public website checks can monitor an accessible URL without a server agent. Host CPU, memory and disk metrics require the Visual Sentinel agent on a supported Linux or macOS host. If your shared-hosting provider does not permit that installation or its required utilities, use website monitoring for the public site and the provider's own tools for host metrics.
How do I evaluate server monitoring before rolling it out?
Server monitoring requires a paid plan or an eligible paid trial. Start with one supported host you administer, verify that metric timestamps keep advancing, and compare a sample with the host's own tools. Connect a representative public website monitor and check the supported alert destinations for your plan. Validate the setup on a non-production host before installing across client servers.
server and website evidence
Monitor Your Servers in 60 seconds.
Server monitoring requires a paid plan. Linux and macOS agent; no Windows agent.
- Linux and macOS
- 60-second agent reporting
- plan-specific alerts