You see the change, not just that one happened
A bare "your DNS changed" is half an alert. Hoppla hands you the record type and the value it moved from and to, so you know in one glance whether that A record swap was your deploy or somebody else's.
DNS Monitoring
Your A record changed at 3am. Hoppla shows you what it changed from, and what to.
Hoppla resolves your DNS records on a schedule and diffs each run against the last. When an A record repoints, an MX drops, or a TXT gets rewritten, you see the old value sitting next to the new one. A failed lookup or an empty answer is the only thing that marks the check down. A record change is an advisory you'll want to read, not a 3am page for a migration you planned yourself.
DNS / SAMPLE OUTPUTIllustrative example
resolve acme.io A 203.0.113.10 → 198.51.100.7 MX ok 41ms CHANGED
Fictional values. Not a live measurement.
01 / What it does
DNS watched for change, not just for resolution
Hoppla resolves your domain's records on a schedule (A, AAAA, MX, CNAME, NS, TXT and CAA by default, plus SOA and SRV if you want them) and keeps every answer. On the next run it diffs the new values against the last. TTL is deliberately left out, so a routine TTL tick never reads as a change. A different value raises an advisory (routine edge-IP rotation within the same CDN is filtered out by default). A lookup that errors or comes back empty is what marks the check down.
What’s included
- ✓Resolves A, AAAA, MX, CNAME, NS, TXT and CAA by default; SOA and SRV can be added
- ✓Value-level change detection between runs, old and new shown side by side
- ✓TTL excluded from the diff, so a TTL tick is never mistaken for a change
- ✓DNS query response time recorded in milliseconds on every run
- ✓Fails only on a lookup error or an empty answer, never on a record change
- ✓Connectivity canary: if our probe loses its own network, the target is recorded as up, not failed
- ✓SSRF-guarded resolution, riding the same monitor as your other checks
02 / How it works
Under the hood.
01
Resolve the record types you care about
On each run Hoppla queries your configured record types (A, AAAA, MX, CNAME, NS, TXT and CAA out of the box) and records every answer it gets back. The outbound resolution is SSRF-guarded: nameservers taken from your zone are only queried on public addresses, so a record pointing somewhere it shouldn't can't be used to probe Hoppla's internal network.
02
Diff against the last known answer
Hoppla compares this run's values to the previous run's, type by type. TTL is excluded on purpose: a counter ticking down between resolutions is normal and never registers as a change. Only the actual record values get matched.
03
Tell you what moved, old to new
When a value changes, Hoppla raises an advisory with the record type and the before-and-after values. A record change is informational. It never marks the monitor down, because a planned migration is a change you want to see, not an outage to be woken for.
04
Fail only on a broken lookup
The check goes down for one of two reasons: the lookup errored, or it returned no records at all. If Hoppla's probe loses its own connectivity (its canary hosts don't answer), it records the target as up rather than inventing a failure, so a network outage on our side doesn't turn into a false alarm on yours. Every run also stores the query response time in milliseconds.
03 / Why it matters01old → new 02TTL excluded 03errors only
The part that actually moves the needle.
Change detection without the noise
TTL counts down between every resolution. Diff it and you'd get an alert on nearly every run. Hoppla leaves TTL out of the comparison, so a notification means a value worth looking at actually moved, not the clock.
A change is advisory, a failure is a broken lookup
Record changes never mark the monitor down. And if Hoppla's probe loses its own connectivity, the check records the target as up instead of failing it. What fails is a lookup that errored or came back empty.
04 / For every team
Whoever you are, this lands differently.
Solo SaaS founder
You own the domain and the registrar login, and nobody else does. So the day an A record or your MX changes and it wasn't you, you want to know on the next check, not weeks later, whether it was a fat-fingered edit or a hijacked registrar account quietly repointing your domain. Hoppla resolves on a schedule (every 12 hours by default; you can shorten it) and shows you the old value beside the new one. If you didn't make that change, you see exactly what moved and can act before more of your users land somewhere you don't control.
Small agency
A client moves their domain to a new registrar and the export drops their MX records on the floor. Nothing errors. The site still loads, the A record came across fine, but mail is silently dead until invoices stop arriving. Hoppla watches MX on every client domain and flags the run where it goes from a real mail host to nothing, so you have a real chance to catch the broken migration before the client does.
Large agency
Hundreds of zones across hundreds of clients, and DNS changes constantly: deploys, CDN swaps, vendor migrations. You can't eyeball that. Run DNS on every monitor and you get a change feed across the whole fleet: every A, MX, NS and TXT edit, timestamped with its before-and-after, on each monitor's timeline. An account manager can answer "did anything change on this domain last week?" from the run history, instead of pulling a developer onto a dig session.
Reseller / hosting provider
You resell monitoring under your own brand, and zone integrity is something customers will pay you to watch. Put a DNS check on every customer zone, and any record change, authorized or not (an A repointed off your infrastructure, an NS delegation moved, a TXT rewritten), raises an advisory wearing your brand, on your domain. You can spot a tampered zone early, and the alert that lands is yours, not Hoppla's.
Switching tools
Coming from Oh Dear? Bring your monitors with you.
Import your Oh Dear monitors into Hoppla. Then run both side by side for 24 hours or 7 days before you switch.
- ✓ Guided import
- ✓ Shadow run before you switch
- ✓ Coverage varies by provider
Import from
- Oh Dear
- Uptime Robot
- Better Stack
- Pingdom
- StatusCakeBeta
- CronitorBeta
- Healthchecks.ioBeta
- Statuspage
The importer opens in your workspace once you have access.
Get early accessFOR HOSTERS & RESELLERS
See the reseller program Watch customer DNS zones for record changes, alerting under your brand.
05 / FAQ
Straight answers.
How is this different from DNS Spy or Oh Dear's DNS monitoring?
The core idea is the same: resolve on a schedule, diff the records, alert on change. What's different is that Hoppla's DNS check lives on the same monitor as your uptime, SSL and domain-expiry checks, on one bill and one alert stream, instead of being a separate product or add-on. And the line between advisory and failure is built in: a record change notifies you but never marks the monitor down, so a planned migration doesn't read as an outage.
Will every TTL change spam me with alerts?
No. TTL is deliberately excluded from the comparison. It counts down between resolutions anyway, so diffing it would fire on nearly every run. Hoppla matches only the actual record values, which means a notification tells you a value you care about (an address, a mail host, a nameserver) actually moved.
Does a DNS record change count as my site being down?
No. A record change is an advisory, not a downtime incident. It tells you something changed and shows you what, but the monitor stays up. The check only fails on a real DNS problem: the lookup errored, or it returned no records at all. So a change won't page you the way an outage does.
What if the failure is on Hoppla's side, not mine?
If Hoppla's probe network itself is unreachable, the check assumes the target is up rather than reporting a failure. That keeps a network problem on our end from becoming a false "your DNS is broken" on yours. A failure means the lookup genuinely errored or came back empty.
Your next step
Know when a record changes, and exactly what it changed to.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.