Most MSPs monitor SSL certificates. Far fewer monitor domain registrations, and almost nobody monitors DNS resolution as a documented, historical thing rather than something you notice when the phone rings. Which is odd, because the three failures look identical to the client — “the website is down” — and have completely different causes, different owners, and wildly different recovery times.
An expired TLS certificate is a browser warning you can fix in an hour with a renewal and a reload. An expired domain registration is a nightmare: DNS stops resolving, mail stops delivering, and depending on the TLD and how long it’s been, you may be negotiating a redemption fee with a registrar while the client’s business is offline. Lumping both under “SSL monitoring” and giving them the same 30-day warning is how MSPs end up scrambling.
Weavestream treats a monitored hostname as three independent checks, not one. Here’s how that works and why the separation matters.
Three Checks, Three Thresholds
Every Monitored Domain in Weavestream runs three checks that are configured, enabled, and evaluated separately:
| Check | What it verifies | Recommended threshold |
|---|---|---|
| WHOIS expiry | Domain registration renewal deadline | 60 days |
| DNS validity | Whether the hostname actually resolves | N/A (binary) |
| TLS/SSL expiry | Certificate expiry date and chain validity | 30 days |
The thresholds are the point. A certificate you can renew in an afternoon doesn’t need the same lead time as a domain registration that might be tangled up in a client’s forgotten registrar account with an ex-employee’s email on file. Weavestream lets you set days before expiry per check, per domain — tight windows on the certificates you control, generous windows on the registrations you don’t.
You can also set tighter thresholds on the hostnames that actually matter. The client’s primary domain and payment gateway get aggressive warnings; a marketing subdomain that redirects to a landing page gets a looser one. If every domain warns at the same threshold, technicians start filtering the alerts, and the whole system quietly stops working.
Four Statuses, Including “Not Applicable”
Each check produces one of four states:
- OK — healthy, within threshold
- WARN — approaching the configured expiry threshold
- FAIL — expired, invalid, or unreachable
- SKIP — check disabled or not applicable
SKIP is the one that keeps this usable at MSP scale. Individual checks can be disabled per domain, which matters more than it sounds like it should. A subdomain like api.example.com isn’t separately registered, so a WHOIS check on it is noise. Some TLDs simply don’t publish expiry dates via public WHOIS at all, so the check will fail forever no matter what you do. An internal hostname with a self-signed certificate will fail TLS chain validation by design.
Without a way to mark a check as not applicable, all of those become permanent red badges — and a dashboard with permanent red badges is a dashboard nobody reads. Disabling the check moves it to SKIP, which tells the next technician “we looked at this and decided it doesn’t apply” rather than “something is broken and everyone has learned to ignore it.”
Check Results Are Append-Only History
This is the part that separates a monitoring feature from a status light. Every check run writes an immutable DomainCheck record — one per check, per domain, per run. Nothing overwrites the previous result.
Open a domain’s detail page and you get the full check history: every run, with timestamps and detailed result data, newest first. That gives you answers to questions a live status badge can’t touch:
- When did this certificate actually change? Did someone renew it, or did it silently roll over via ACME?
- How long was this hostname failing DNS resolution before anyone noticed?
- Was this domain healthy on the date of the incident the client is asking about?
For an MSP, that last one is the one that shows up in a post-incident review or a client dispute. “The certificate was valid at the time” is a much stronger statement when you can point at an append-only record than when you’re reconstructing it from memory. It’s the same design principle Weavestream applies to the audit log, credential version history, and article history: the record accumulates, it doesn’t get overwritten.
Rolling Up Into the Expirations Dashboard
Domain expirations — both WHOIS and TLS — feed the same Expirations dashboard as asset warranty dates and password expiry dates:
- Admin → Expirations — every tenant, one view
- [Tenant] → Expirations — a single client
That unified view is the operationally useful one. A quarterly review with a client shouldn’t require opening three modules to answer “what’s coming due in the next 90 days.” Server warranties, software licenses, domain registrations, and certificates all show up in the same place because from the client’s perspective they’re the same category of problem: a renewal deadline somebody has to own.
The rollup also means domain monitoring inherits the platform’s alert system rather than needing its own notification plumbing. A domain crossing its threshold is just another expiration event.
Clients Can See It, If You Want Them To
Each domain has a Visible to clients toggle. Turn it on and the domain — along with its check history — appears in that tenant’s client portal, read-only.
This is worth doing selectively. Domain and certificate status is one of the few technical metrics a non-technical client actually understands, and showing it does real work for you: it makes the renewal conversation concrete (“this one is 40 days out and it’s in your registrar account, not ours”), and it demonstrates that somebody is watching. Like everything in the Weavestream client portal, visibility is enforced server-side per record — a domain that isn’t marked visible isn’t hidden in the UI, it isn’t returned at all.
It Runs on Your Server
Checks execute in the worker service via BullMQ on a configurable schedule, distributed across replicas if you run more than one. Failed checks retry with exponential backoff.
Two consequences of self-hosting worth knowing. First, the checks run from inside your infrastructure, which is usually what you want — the TLS handshake is a real handshake from a machine you control, not a probe from a third-party SaaS whose IP ranges may or may not be allowlisted at the client’s edge. Second, that same fact is the source of most surprises: the DNS check uses the worker container’s resolver, which can differ from your laptop’s. If a domain resolves for you but fails in Weavestream, check from inside the container before assuming the feature is wrong.
The same applies to internal hostnames. A real TLS handshake against a self-signed internal certificate fails chain validation, correctly. Either disable the TLS check for that host or add the certificate to the worker’s trust store.
Why This Belongs in the Documentation Platform
The argument for consolidating domain monitoring into your self-hosted IT documentation platform isn’t that a dedicated monitoring tool can’t check certificates. It obviously can, usually with more bells on it.
The argument is context. When a certificate warning fires at 7am, the useful question isn’t “is this certificate expiring” — the badge already told you that. It’s “whose domain is this, where’s the registrar login, which server terminates TLS for it, and who at the client authorizes the renewal spend.” In a standalone monitoring tool, every one of those answers lives somewhere else. In Weavestream, the monitored domain sits inside the client’s record, one click from the credential vault entry for the registrar, the asset record for the load balancer, and the article describing the renewal procedure.
That’s the whole case for integrated MSP domain monitoring: not better checks, but checks that land next to everything you need to act on them.
Getting started: open a tenant’s Domains section, click New Domain, enter the hostname, and enable the checks that apply with thresholds that match how much lead time each failure actually needs. The first check runs in the background within a few minutes. Full details in the Domain & SSL Monitoring reference and the Monitoring Domains guide.