Troubleshoot common problems
Find the relevant evidence and send a useful support request.
Domain is critical, but this record looks healthy
Check every active monitor on the domain. A different record may be failing, or an open incident may still need more successful checks to confirm recovery. Compare latest-check timestamps rather than relying on an older history row. Refresh the page; repeated contradictory state should be reported to Support.
Missing record or inconsistent answers
Confirm the exact hostname and record type. SPF is commonly stored as TXT; DKIM usually uses a selector under _domainkey. An apex MX check does not inspect a subdomain's MX records.
Expand DNS sources: distinguish a completed empty answer from NXDOMAIN, SERVFAIL or timeout. Compare authoritative answers with cached public-resolver answers. A different answer may be intentional; use the agreement rule that matches your service rather than disabling all checks.
Notifications did not arrive
Check that the monitor sends notifications, the organization has the intended target and the incident actually reached its confirmation threshold. Email notifications follow incident opening and recovery rather than every individual check. SMTP acceptance does not prove inbox delivery; also check spam and the destination address.
Ask for help with evidence
In the app, open Support and include the selected organization, domain/monitor link, approximate time with timezone, visible error and what you expected. If shown, include the request reference. Do not include passwords, API tokens, cookies or recovery codes.
A screenshot can help explain a state, but check it for private information before sending it. Report persistent unknown results rather than interpreting missing measurements as a pass.
Documentation reviewed: 8 October 2026. Results describe configured checks and available evidence, not a complete security or service-availability guarantee.
Troubleshooting and contacting Support