Monitoring Concepts

Understanding how Merlonix classifies results lets you tune alert thresholds and interpret the dashboard accurately.

SSL monitoring

Merlonix connects directly to your asset on port 443 using a raw TLS socket and reads the certificate from the server handshake. This gives it the real fingerprint, public key algorithm, and signature algorithm — not just what a CA database says.

What gets checked

Check	What triggers a flag
Expiry	Certificate expires in ≤ 30 days (warning) or ≤ 7 days (critical)
Key downgrade	Key algorithm weakened vs. the previous check (e.g. RSA 4096 → RSA 2048)
Signature algorithm downgrade	Signature algorithm weakened (e.g. SHA-256 → SHA-1)
Issuer change	Certificate issuer changed unexpectedly — often a rotation, occasionally a hijack
SANs mismatch	Subject Alternative Names no longer include the monitored hostname

Severity levels

Level	Condition
`info`	Expiry > 30 days, no anomalies
`warning`	Expiry 8–30 days, or a low-risk anomaly like issuer change
`critical`	Expiry ≤ 7 days, key downgrade, signature downgrade, or SANs mismatch

Fallback to crt.sh

If the TLS socket connection is blocked (firewall, non-standard port), Merlonix falls back to querying crt.sh for the most recent certificate transparency log entry. The fallback returns expiry and issuer but not key algorithm or real fingerprint — these appear as — in the detail view.

DNS monitoring

On the first successful check, Merlonix stores a baseline snapshot of all DNS records for the asset's hostname: A, AAAA, MX, TXT, CNAME, NS, and SOA.

Subsequent checks diff against this baseline. If anything changes, the check is classified as drift.

Drift classifications

Classification	What changed
`A_record_changed`	IPv4 address changed — could be a CDN swap or misconfiguration
`AAAA_record_changed`	IPv6 address changed
`MX_record_changed`	Mail routing changed — high-risk, can affect deliverability
`TXT_record_changed`	SPF, DKIM, or other TXT records changed
`CNAME_changed`	CNAME target changed
`NS_changed`	Name servers changed — highest risk, can indicate domain takeover
`record_removed`	One or more records present in baseline are now absent
`record_added`	New records present that were not in the baseline

Tip: After an intentional DNS change (CDN migration, new MX provider), open the asset and click Update baseline to reset the drift reference.

Severity

DNS drift is always warning unless the classification is NS_changed or record_removed involving MX or NS records, which are critical.

Vendor monitoring

Merlonix polls the status APIs of 11 infrastructure vendors every 5 minutes. When an incident is detected, it is summarised by an LLM and cross-referenced against your tenant's stack tags — the services your clients rely on.

Covered vendors

Stripe, Cloudflare, Anthropic, OpenAI, Vercel, GitHub, Slack, Shopify, Google Cloud, AWS, and Azure.

Stack tags

You set stack tags on your tenant profile (Settings → Stack tags). Tags follow the shape vendor.service, for example:

stripe.payments
aws.ec2
cloudflare.cdn
github.actions

When a vendor incident is detected that overlaps with one of your stack tags, Merlonix fires an alert. Tenants with no matching stack tags do not receive vendor alerts for that incident — reducing noise.

Impact levels

Level	Meaning
`none`	Vendor reports all systems operational
`minor`	Degraded performance on one or more components
`major`	Partial outage affecting multiple components
`critical`	Full outage or widespread data-path disruption

Alert deduplication

Alerts are deduplicated on a 24-hour window per (asset_id, check_type, severity, classifier) tuple. This means you receive at most one alert per asset per day for the same condition — until the condition resolves and fires again.

Deduplication does not prevent the second alert if the first one was acknowledged or resolved: a resolved condition that recurs generates a fresh alert.

Next: add your first channel in Settings, or return to Getting Started.