A DNS lookup failure means Uptime Basics could not obtain a usable public IP address for the monitored hostname. The HTTP request cannot begin until DNS resolution succeeds, so there is no HTTP response code for this type of failure.
An existing website can have a healthy server and still be unavailable to visitors when DNS is broken.
How DNS is used during a check
Uptime Basics resolves the hostname for each availability request and connects to the resolved address. Redirect destinations are resolved and validated separately before they are requested.
The service does not monitor private, loopback, local, reserved, or unsupported targets. If a hostname resolves to a blocked address, it is rejected rather than requested.
A new monitor must resolve to a valid public destination during creation. An existing monitor can later report DNS failures if records, nameservers, registration, or the DNS provider change.
Confirm the affected hostname
Check the exact hostname in the monitor URL. These can have different DNS records:
example.comwww.example.comapp.example.comapi.example.com
A working root domain does not prove that a monitored subdomain resolves. Also inspect the hostname at every redirect destination.
Common causes
Missing or incorrect records
The A, AAAA, CNAME, or alias record may be absent, misspelled, or pointing to an old destination. Confirm the record exists in the authoritative DNS zone.
Nameserver delegation problem
The registrar's assigned nameservers must match the authoritative DNS provider. A zone can look correct inside its provider while the public internet is delegated somewhere else.
Recent DNS change
Resolvers can retain earlier answers until their TTL expires. During a change, different regions may temporarily receive different results. Confirm both the old and new destinations can serve traffic during the migration where possible.
Expired or suspended domain
An expired registration, registry hold, or DNS-provider suspension can remove normal resolution. Check the domain registration and provider account status.
DNSSEC failure
Incorrect DS records, expired signatures, or a broken DNSSEC chain can cause validating resolvers to reject an otherwise visible record. Confirm DNSSEC status with the registrar and authoritative provider.
Intermittent provider or authoritative-server failure
One authoritative nameserver may be unreachable or return inconsistent data. Query every authoritative server and compare its answers.
Private or reserved result
A public monitor cannot request a hostname that resolves to a private or reserved address. Use a publicly reachable endpoint on HTTP port 80 or HTTPS port 443.
Troubleshooting steps
- Copy the hostname from Monitor Details exactly.
- Check its public A, AAAA, CNAME, or alias answer using more than one independent resolver.
- Confirm the registrar delegates to the intended authoritative nameservers.
- Query each authoritative nameserver for consistent records.
- Review recent DNS, hosting, CDN, and domain-registration changes.
- Check DNSSEC if it is enabled.
- Inspect redirect targets for a second hostname with broken DNS.
- Review Detailed Logs and regional Confirmation to see whether the problem affects multiple locations.
Your computer may continue to load the website from a cached answer. Test through another network or resolver, but do not treat one successful local lookup as proof that authoritative DNS is healthy.
After correcting DNS
Allow time for caches to expire according to the previous record's TTL. A successful monitoring cycle resets the consecutive-failure count or resolves a confirmed outage. The dashboard can take another automatic refresh to display the recovery.
Do not delete and recreate the monitor. Keeping it preserves the incident and check history needed to measure the DNS interruption.
What will not fix a DNS failure
- Adding an accepted HTTP status code, because no HTTP response exists.
- Increasing the request timeout when the authoritative DNS configuration is incorrect.
- Changing GET to HEAD.
- Installing a new TLS certificate before the hostname resolves correctly.
When to contact Support
Contact Support if independent public resolvers consistently return valid public addresses but Uptime Basics continues to record DNS failures across multiple checks.
Include the monitor name, URL, failed timestamps, authoritative nameserver names, expected public record type, and regional Confirmation summary. Do not send registrar passwords, DNS-provider credentials, transfer codes, or private keys.