Reading a page
This page is for whoever was given an account on a Webmonit somebody else runs — a hosting admin, a provider, the person who looks after the machines. You are reading their monitoring, narrowed to what is yours.
Most accounts are read-only. Nothing you click can change what is watched or stop a check; the buttons that would do that are not drawn for an account that may not use them. So look around freely: these pages report, they do not act.
The things on the screen
A handful of words carry everything on these pages, and they never mean anything else.
A site is a domain name and what it serves. It is normally served by a machine the admin runs; it can also be served somewhere else entirely, and be watched from outside all the same.
A host is the machine — the physical or virtual server a site lives on. Webmonit calls it a host and never a "server", because server in this product means one thing only: the Webmonit service itself, the program that does the watching.
A check is one observation, run again and again: fetch the site's page, resolve its name, look at its certificate, ping its host, open a port. Each run produces a result — when, from where, what came back, how long each step took. Every result is kept.
A monitor is a check plus the decision to watch it: how often, past what point it counts as too slow, and who is told when it fails. Several monitors can point at the same thing; the check still runs once.
An incident is a period during which something was not right. It opens when a failure is confirmed, carries what the thing actually answered while it was failing, and closes when it recovers. Incidents are numbered — #1428 — and that number is the handle for talking about it.
An event is something noticed that is not a failure: a DNS record changed, a certificate was renewed, a site moved to another host, an agent came back. The interface lists these under History, in the tab called Changes.
And the admin is the person who runs this Webmonit and the machines under it. When a page here says "ask the admin", that is who it means.
The colours
Every state has a colour, and the same colour means the same thing everywhere — on the little round dot beside a name, on the word-shaped tag, on the cards at the top of a page.
Green is well. Amber is answering but not right. Red is a confirmed failure. Blue is maintenance — expected, declared or recognised. Grey is no information: nothing measured yet, or checks stopped. Purple marks a domain that points somewhere outside the admin's machines. A muted blue-grey marks a fault somebody has taken in hand.
Grey deserves a second look, because it is the one colour people misread. Grey is not good news and not bad news. It is the absence of a measurement, and the honest thing to do with it is find out why nothing was measured.
The words for a state
up — everything answered as expected. (The machine's own word for this is ok; the interface writes it up.)
degraded — it answered, and something about the answer is wrong: it took longer than the threshold the admin set, or one of the two address families failed while the other worked, or the certificate is close to expiry, or the page that came back looks like a web server's default page rather than the site. A visitor might notice nothing. It is still worth knowing.
down — a failure, confirmed. Not one bad answer: a failure that was re-checked and held (see Understanding alerts).
maintenance — the check recognised a maintenance page, or the site answered a 503 with a "come back later" header, or the admin declared a maintenance window covering it. Blue, not red, because nothing here is a surprise.
acknowledged — still down, and somebody has written that they have it in hand, with their name, the time, and usually a note about what they are doing. It is counted apart from down on purpose: the fault is still there, but it is no longer waiting to be noticed.
unknown — no check has run on this yet, or the monitoring itself could not see at that moment. A freshly added host can bring hundreds of domains that are honestly unknown for a few minutes.
paused, suspended, disabled, expired — the checks were stopped, or the hosting panel says the site was stopped by the admin, by the reseller above, or by its own owner. Grey, and no alert comes from them.
pointing elsewhere (external in some places) — the domain's records send visitors to an address that is not one of this admin's. It is not served here, so its failures are not this fleet's failures. It stays watched, in case it comes back.
The duration beside a state
Almost every state has a duration next to it, written short: 48s, 27m, 3h 12m, 9d. Seconds, minutes, hours, days.
It says how long the thing has been in the state it is in now — not how long the fault lasted in total, and not how old the site is. A red dot with 3h 12m means three hours and twelve minutes of confirmed failure, still running. A green dot with 9d means nine days without a change of state, which is exactly what you want to see.
On an incident that is over, the duration is the length of the incident: how long it lasted, from the first failing result to the recovery. On a site's own page, the state is given with a full date instead — the day and the time it started.
Answering is not the same as being well
This is the distinction that makes the rest readable, and it is the reason a page can be amber while the site opens perfectly in your browser.
A site can answer and still be wrong. It can be slow — past the threshold, the result is degraded even though the page arrived. It can answer over IPv4 and fail over IPv6, which a visitor whose network prefers IPv6 will feel and you will not. It can serve a valid page behind a certificate that expires in nine days: perfect today, broken for everybody in nine days if nothing renews it. It can answer the web server's default page — the domain resolves, the machine replies, and the site itself is gone. It can be behind a content delivery network (a service in front of the site, Cloudflare and the like) which answered on the site's behalf, in which case what was measured is the network's edge and not the site.
So the status word tells you one thing: what drove the state. Everything else that was found wrong on the domain is listed separately, in the column named What is wrong, one short tag per fault. Those tags each have a name and an explanation of their own on Common problems.
Some checks also leave a remark — a line marked with a small flag under the site's figures, such as a certificate close to expiry whose renewal has not run, or a DNS zone split between two sets of name servers. A remark is not an incident. It is the monitoring saying: this will matter later.
The figures on a site's page
Across the top of a site's page there are six cards, and they answer six different questions.
Availability 24 h and availability 30 days are each given twice: raw is the share of the time the site was not down; net is the same figure with declared or recognised maintenance taken out. A site taken down deliberately for an hour at night is down in the raw figure and untouched in the net one. Contracts are usually written about the second; honesty is served by showing both.
Response is the last total time — everything, the page body included, as a visitor waits for it — with the average over the last 24 hours beside it.
Server wait and RTT split that total into its causes. RTT (round-trip time) is how long a packet takes to reach the host and come back: the network's share, the ping. Server wait is measured from the moment the request left to the first byte of the answer: the machine's and the application's share. If the response is slow and the RTT is high, the network is the suspect. If the RTT is small and the wait is long, the machine or the site's own code is.
Certificate counts the days left on the TLS certificate — the one behind the padlock in a browser — and names who issued it. Under fourteen days it goes amber, because a certificate that stops renewing gives you a fortnight of warning and then breaks the site for everybody at once.
DNS reports the domain's records as the resolvers (what visitors' machines ask) and the authoritative name servers (what the domain publishes) answer them, with the time each took. The records are written down each time they change, so the button History beside them shows the domain's DNS as it was at any moment: pick a date and an hour, and the page shows what the name answered then — what has gone since struck through, what came since in green — with the certificate and the registration as they stood at that moment, and every change in order, each one opening the state it began.
Some sites also carry a cold and warm pair: the same request run twice, a breath apart, on fresh connections. The first is what a first visitor gets; the second is what the site's caches give the next one. The gap between them is what the caching buys.
Where the history is
Every result is kept, and there are four places to read the past.
A site's own page ends with a Timeline: its incidents, its events and the machines it has been served by, merged on one axis, newest first, one line each.
History in the top menu holds three tabs — Incidents (everything that opened, with its cause, its duration and whether anyone acknowledged it), Changes (the events: records that moved, certificates renewed, sites migrated) and Alerts sent (every notification, where it went, and whether it arrived).
The charts are read over a window you choose, from 15 minutes to 30 days. Every chart on a page shares that one window, so two charts can be compared. Drag to move through time, hold shift and drag to pick a span, hold alt and use the wheel to zoom, double-click to come back to live.
On a response time chart, each measurement holds until the next one: a check that runs every quarter of an hour draws flat steps, not slopes between two points. A period where the check failed is a red band (amber when it was degraded) that lasts until the next result. The curve stops there, because a run that got no answer measured no response time; the tooltip says how long it waited. A gap with no band means nothing was measured at all.
On a machine's charts, a time when the agent sent nothing — the machine was down, or the agent was — is painted red across every chart, and no curve crosses it: what did not arrive is never drawn as if it had. The agent keeps what it could not deliver and sends it when the server answers again, so a red stretch is a time when nothing was measured, not a network hiccup. Pointing at it says when it started, when it ended, and how long it lasted. The same red covers a site's own CPU and memory charts. While the machine is still silent, the dials show no needle and every chart's figures read nothing received since the time it stopped, instead of the last value that came in. The charts of the checks Webmonit runs itself — services, response times — are not covered: they are measured from the server, and they say for themselves whether the machine answered.
The Wall is the screen meant to be left open on a screen of its own: only what is wrong, the machines before the sites they carry, and a plain "all well" when there is nothing.
When Webmonit itself cannot see
If a banner appears saying the monitoring cannot reach its reference addresses, read it before you read anything else. It means the machine Webmonit runs on lost its own network. Everything would look down from there, which would be a lie about your sites — so nothing is alerted while that lasts, and the pages tell you plainly that what they show is about the monitoring and not about the fleet.