DNS monitoring
Resolve and validate your DNS records continuously.
What it watches
A DNS monitor resolves one record on your interval and fails when resolution fails. A, AAAA, CNAME, MX, TXT, NS: pick the record, name the host, and the check asks the question a browser would ask first.
It's the layer under everything else you watch. When DNS is wrong, your server is fine and nobody can reach it, and every other check you own goes red for a reason none of them can explain.
Resolving isn't the same as resolving correctly
A record that disappears takes your site down loudly. A record that changes to someone else's address does something worse: it resolves, fast, and serves a stranger.
Set an expected value and the check fails when the answer doesn't contain it. That catches the hijack and the fat-fingered edit, not just the outage — and it's the difference between "DNS answered" and "DNS answered what I published".
It remembers what the answer used to be
The resolved records are stored and only rewritten when the answer set actually changes, so the monitor can tell you when your records last moved, not just what they say now.
A change you didn't make is worth a look. A change you did make, showing up on the timeline next to a deploy, is how you confirm propagation without reaching for dig on four machines.
Name a host and a record
The target is a bare hostname: no scheme, no path, no port. An IP address is refused, because resolving an IP is not a question DNS can answer.
curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{
"type": "dns",
"host": "example.com",
"dns_record_type": "A"
}'Tune it when the defaults aren't right
Highlighted is the default.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Every outage,
written down as it happens.
A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.