How it is built

Thirteen decisions

• A verdict, not a graph. Every pair, pool and server says what is wrong and why, in words, and the reason opens the row it names. The Analyze verdicts (why did it restart, why did it fail over, is anything climbing) come with their confidence and with what would settle them, and say when they are an estimate rather than a fact the appliance stated.
• Empty is not the same as could-not-read. Anywhere a panel can show nothing, it says whether it asked and there was nothing, or could not ask, and why. This is the defect most monitoring tools ship and the one that costs the most at 2 a.m.
• Parsers are written from captures, not from documentation. Every line that reads an appliance's output was written against verbatim output from a real one, and a shape that has not been seen is asked for, not guessed. Where the product has an API, the API is used instead: NITRO for NetScaler changes, XenAPI for pools, the Hyper-V module for hosts, the Windows Update Agent for updates.
• A pair is one thing. NetScaler HA pairs and XenServer pools are atomic units: both nodes' clocks, one verdict, one category move.
• A push is a hint; the system is the answer. A state change in an appliance’s syslog arrives in seconds but can be lost or forged, so it is never stored or alerted on as it stands: it makes Vantage ask the appliance, and the appliance’s answer is what counts. An appliance that stops sending is said to have gone quiet and is polled again, rather than assumed healthy.
• One install; the cloud is opt-in. A Windows Server VM on your network; nothing on the appliances; one small agent per Windows server. The portal is contacted when you press a button; the three timed contacts (the Uptime page, the fleet report, the remote console) are opt-ins, each needing a key the portal issued for that installation.
• Reading and changing are sold apart, and behave apart. The reading modules never write. A management module adds specific, confirmed, audited actions, in the system's own API, as the signed-in operator, with a separate read-write account where the appliance needs one.
• Security by construction, not by setting. No operator password stored, no TLS bypass switch, certificates pinned before a credential is sent, the agent not an administrator. There is no configuration in which the product is less safe than the page describes.
• A figure that cannot be earned is not printed. There is no security score out of a hundred and no health percentage: a figure over an estate where two servers could not be read counts a machine nobody asked as a pass. Where a number would be a guess, the page gives a word and the coverage beside it — “read on 11 of 12, 1 not read, which is not a pass”.
• Every correlation carries its provenance. On the estate map each link says how it was observed — the product itself said so, a second observation confirmed it, or it was matched by address alone — and an answer is only as strong as its weakest hop. “Nothing depends on this” is never said while a source could not be read.
• A block that depends on Vantage fails open. Where a NetScaler asks Vantage whether to drop an address (the learned list, the shared list), it asks through a virtual server whose monitor watches Vantage’s callout port; if Vantage stops answering, the monitor marks it down and requests are let through rather than held or dropped. A block list you keep by hand lives on the appliance itself and holds while Vantage is down.
• A lockdown policy is signed and holds offline. An enrolled machine checks the policy’s signature before applying it, and again before using its cached copy while it cannot reach the dashboard; an install approved over the phone is a code the machine verifies itself, tied to that request.
• Honest words on the page. When a reading is from the last poll rather than live, the panel says so. When a feature is product knowledge rather than a tested capture, the docs say so. When something is not built, this site says so.

What to ask any vendor, us included