The Question After The Alert
I keep coming back to the same moment.
An agency learns that a client site is in trouble. The homepage is timing out. Several pages are returning errors. A checkout or a lead form is failing. The site was fine earlier, and now it is not.
The outside evidence answers the first question. Something a visitor depends on is broken, and it broke around this time.
The next question is harder.
What was the server doing?
Was the web service stopped? Was PHP-FPM sitting with a queue and no idle workers? Was the host actually quiet, which is a useful clue that the problem may be somewhere else? Were other client sites on that same machine failing in the same few minutes?
That is the gap I am closing with the Linux server agent, and with the intelligence that decides when a host report belongs next to a site incident.
The Portfolio Is Still The Working View
I wrote about the larger direction in MetricPoints Is Becoming the Website Assurance Layer for Agencies. The portfolio is still the place an agency works from. Which sites need attention. Whether several problems may be related. What evidence exists. What is still unknown.
The server agent adds the host underneath that view, for the servers an agency chooses to connect.
Public checks still decide whether a site is failing. A host snapshot can describe the same window of time. The intelligence I care about is the join between those two stories, including the cases where the join is too weak to make.
External Monitoring Still Comes First
This follows the decision in Protection Should Not Have To Start With An Installation.
An agency can watch a public website before anything is installed. Availability, certificates, DNS, headers, forms, checkout paths, and visual changes do not wait on a plugin, a browser script, or a server agent.
The agent is optional, on every plan, including the free Developer plan. It is for the hosts where dated server evidence would help an investigation.
An owner or admin generates a short-lived install command from Servers and runs it with administrator access on an Ubuntu or AlmaLinux host. The agent reports over outbound HTTPS. MetricPoints does not need an inbound port on that machine.
A connected agent does not prove that a website is down. A missing or stale report is a connection gap. I want that gap to stay a connection gap, so a quiet agent cannot masquerade as a site outage.
The shorter product explanation lives on the Linux server agent page. This post is why I am building it.
What A Report Actually Contains
Each report is a short, dated snapshot.
CPU busy across the whole host. One-minute load. Memory. Root disk. Selected service states. A bounded process summary, limited to names and shares of the machine, without command lines or credentials.
On common Nginx setups, the agent can also read domains from virtual host files and offer a provisional match to sites already in that agency portfolio.
Provisional is the right word. A domain found on a host is a clue that this server may be serving that site. It is not a complete map of production, and it is not proof that this host caused a public failure. If two fresh agents both match the same domain, the match is ambiguous, and MetricPoints refuses to pick one.
A single busy sample is not a finding. High CPU by itself does not open an incident and does not send an alert. The public site checks remain the reason an agency gets interrupted.
When A Host Report Belongs Next To An Incident
The part I am most interested in is the explanation, not another chart.
When a current public incident is underway, and one fresh agent match lines up with that site within a few minutes of the failure, MetricPoints can place the host evidence beside the site. The same explanation shows up in All Sites, Site Health, the server detail, and the incident email or Slack alert that was already going out.
That explanation has to carry both sides. Supporting evidence, such as a stopped web service or a PHP-FPM queue with no idle workers in the same window as the public failure. And what remains uncertain: a gap between the host sample and the outside check, a match that is not clean, a service state that does not agree with the outage.
If the timing is stale, the link is missing, or more than one server could be the origin, the incident stays as it was. The host stays out of the cause story. A smaller explanation is more useful than a confident one built on a guess.
On an eligible incident, a read-only diagnosis can look at web and PHP-FPM context for that domain and store what it found, including the signals that argue against a simple host story. It does not change the site. It does not restart anything.
Several Client Sites On One Server
This is the scenario agencies describe most clearly.
Two or three client sites start failing around the same time. In a flat list they look like separate emergencies. Someone then remembers they share a server.
Infrastructure groups already give the agency a place to record that shared server, CDN, firewall, or DNS provider. The agent makes the host less of a memory.
When the current failures are the kind that can come from an origin, every affected site has one fresh link, and those links point at the same connected server, MetricPoints can attach that dated host report to the one shared incident. The affected sites stay listed together. The server evidence is context for the investigation.
DNS and certificate problems stay with the edge. A quiet CPU reading beside a public outage is useful in the other direction. It says the machine was not obviously exhausted at the minute the sites failed.
None of that is a root-cause stamp. It is a better place to start, before each site is treated as an unrelated failure.
Some Explanations Do Not Need A Server Agent
The agent is one source of evidence. It is not the only way MetricPoints can say something precise.
A homepage can return a successful response while a lead form, checkout, search, or booking flow is still broken. When both checks are current, the portfolio should say both things. The passing main page leaves the broken function in place. That contrast comes from the public checks alone.
A failure that keeps returning near the same time of day is another kind of clue. Recent history can show the pattern. The useful next look is backups, cron jobs, deploys, and traffic around that time. The pattern does not prove a scheduled task on the current server caused it. Agent samples cover a short window, and a current domain match cannot reconstruct where a site lived two weeks ago.
In this product, intelligence means a dated explanation with its limits written on it.
Repair Stays A Separate Decision
Routine reporting is read-only. The agent sends bounded summaries. It leaves raw access logs, request bodies, and credentials on the host.
There is a narrow PHP-FPM restart path in controlled testing. It applies only to an eligible incident on a non-client-facing site, and only after an explicit approval, a local permission for that exact service, and the safeguards around delivery. Automatic restarts are not available. A reported restart still waits for a later public check before the recovery can be called verified, and the action does not by itself close the incident.
I am being slow here on purpose. An agency needs a product that shows its work before it touches a service.
Know Before The Client Knows
The promise is the same one I have been writing toward.
Know before the client knows.
Then have enough evidence to know where to look. The public failure. The sites that share infrastructure. The host snapshot from the same few minutes, when a server is connected. The business function that is still broken after the homepage loaded. The uncertainty, stated plainly, when the evidence is not strong enough.
There is still a lot to prove on real hosts and real agency portfolios. The agent stays optional because external monitoring has to stand on its own.
If you manage client websites, subscribe. I am sharing this as I build it, including the limits I am refusing to paper over.