When included in your active plan, an uptime check can change one DNS address record to a backup address after repeated failed checks. Both the primary and backup services must already be prepared to serve the same hostname.
IN THIS ARTICLE
01 Prepare the two destinations
Deploy the website or application on both servers, including HTTPS certificates and required data. DNS failover does not copy files, synchronise a database or transfer logged-in sessions. For shops and other applications that accept writes, plan how the backup uses current data before enabling automatic switching.
The module watches a supported A or AAAA name with a single address. A name containing several addresses may not be offered for this workflow. Only a public destination can be monitored.
02 Add a check
- Open the domain's Health section and locate Uptime checks.
- Select the exact A or AAAA record.
- Enter the backup address of the same address family as the record.
- Choose HTTPS, HTTP or a TCP-port check.
- Set the correct port. For a web check, enter a path that reliably represents availability.
- Select Add uptime check and inspect the saved configuration.
- Confirm subsequent check results and the last-checked time.
How quickly will a DNS failover change reach visitors?
Checks run from the monitoring server on its scheduled cycles. The supplied workflow requires repeated failed rounds before switching and repeated good rounds before returning to the primary. A switch is a real DNS change, recorded in history, and its effect on visitors also depends on DNS caches. This is not an instant worldwide health assessment.
The web check treats a response other than a server error as up. A page returning an application error with an otherwise acceptable HTTP status may therefore look healthy. Choose a suitable endpoint and continue application-level monitoring where your business requires it.
03 Test and remove carefully
Use a controlled hostname for the first test. Verify the backup through the real hostname, observe the DNS change and confirm recovery behaviour. Do not intentionally take a production server down merely to test a monitor.
If you edit the watched record manually, recheck the monitor so its primary and backup expectations remain appropriate. Removing a check while the record is on its backup can trigger restoration to the primary as part of cleanup. Confirm the primary is usable and inspect the resulting record before considering the change complete.