UptimeHunt Docs
Status Pages

Use a custom domain for your status page

Point your own domain or subdomain at your UptimeHunt status page and serve it from a URL you control.

Custom domains

By default, every status page is served at <slug>.status.uptimehunt.io. If your plan includes it, you can point your own domain or subdomain at your page instead — so visitors go to status.acme.com or acme.com (at the apex) rather than a UptimeHunt URL.

Plan availability

Custom domains are available on Team and Scale plans, and Enterprise. Each plan's limit is shown on the Status Pages overview.

DNS setup

Choose whether you're pointing a subdomain (like status.acme.com) or your apex domain (like acme.com itself), then follow the matching steps. Both paths result in the same visitor experience — the only difference is the DNS records required.

Add a CNAME record

Create a CNAME record at your subdomain pointing to the UptimeHunt endpoint:

  • Name: status (the subdomain label)
  • Type: CNAME
  • Value: status.uptimehunt.io

The exact record to publish is always shown in your page's Settings → Custom domain card — copy it from there. The CNAME target is the same status.uptimehunt.io for every page; UptimeHunt routes the request to the right page from the incoming hostname, so you never need to embed your slug in the record.

Example (in your DNS provider's UI or via API):

status.acme.com CNAME status.uptimehunt.io

Add the verification TXT record

UptimeHunt proves you own the domain with a plain TXT lookup — this is unrelated to whatever ACME challenge cert-manager later uses to obtain the TLS certificate. Publish a TXT record at the verification name with the value uptimehunt-verify=<token> (the token is shown in the UptimeHunt Settings tab once you initiate setup), then click Verify:

  • Name: _uptimehunt-challenge.status (the challenge name under your subdomain)
  • Type: TXT
  • Value: uptimehunt-verify=<token> (the token is shown in the UptimeHunt Settings tab once you initiate setup)

Example:

_uptimehunt-challenge.status.acme.com TXT "uptimehunt-verify=<token>"

The underscore prefix (RFC 8552) keeps the verification signal separate from your public subdomain, preventing CNAME conflicts. You can leave this record in place permanently; it does nothing after the certificate issues.

A CNAME record cannot coexist with any other record type at the same name — that's a DNS hard rule. By putting the verification TXT at the underscore name instead, we avoid that collision entirely.

Add A and AAAA records

CNAMEs don't work at the apex (the bare domain), so use A and AAAA records to point directly to UptimeHunt's infrastructure:

  • Name: @ or leave blank (the apex)
  • Type: A
  • Value: 46.171.116.70

And:

  • Name: @ or leave blank (the apex)
  • Type: AAAA
  • Value: 2001:678:12b4:70::1

Example:

acme.com A    46.171.116.70
acme.com AAAA 2001:678:12b4:70::1

ALIAS/ANAME records

Some DNS providers (Route53, Cloudflare, etc.) support ALIAS or ANAME records, which act like CNAMEs at the apex. If your provider supports it, you can point an ALIAS to status.uptimehunt.io instead — simpler and more resilient to IP changes. Hetzner DNS does not support ALIAS, so stick with the A+AAAA pair.

Add the verification TXT record

UptimeHunt proves you own the domain with a plain TXT lookup — this is unrelated to whatever ACME challenge cert-manager later uses to obtain the TLS certificate. Publish a TXT record at the verification name with the value uptimehunt-verify=<token> (the token is shown in the UptimeHunt Settings tab once you initiate setup), then click Verify:

  • Name: _uptimehunt-challenge (the challenge name at the apex)
  • Type: TXT
  • Value: uptimehunt-verify=<token> (the token is shown in the UptimeHunt Settings tab once you initiate setup)

Example:

_uptimehunt-challenge.acme.com TXT "uptimehunt-verify=<token>"

Again, the underscore prefix keeps this separate and avoids conflicts. Leave it in place permanently after the certificate issues.

CAA records (important if you have one)

If your domain already has a CAA record (a certificate authority authorization list), it must include letsencrypt.org, or the certificate will never issue:

acme.com CAA 0 issue "letsencrypt.org"

If you have a CAA record and it doesn't list letsencrypt.org, your domain's certificate request will be rejected by Let's Encrypt — even though your DNS is otherwise correct. This is a common gotcha at the apex, where CAA records are more likely to exist. Check your apex CAA records before setting up the custom domain.

After DNS is live

Once your DNS records are in place (both the CNAME/A+AAAA and the TXT verification record), click Verify in the UptimeHunt Settings tab. UptimeHunt will:

  1. Check that the verification TXT record exists and matches.
  2. Order a TLS certificate from Let's Encrypt.
  3. Update your status page to serve at your custom domain.

The whole process usually takes under a minute. Your page goes live at the custom domain as soon as the certificate issues, and the custom domain becomes your page's single public address: the old <slug>.status.uptimehunt.io URL automatically redirects to it, so any existing links or bookmarks keep working while everyone lands on your domain.

Domain state

Your domain will show one of six states in the Settings tab:

StateMeaning
Pending DNSYou've submitted the domain. Are the records published yet? Click Verify once they are.
Ownership verifiedThe verification TXT record has been proven — the platform is now provisioning your certificate.
Certificate issuedThe TLS certificate has been obtained; UptimeHunt is waiting for routing to prove out before it fully takes over.
ActiveLive — this is your page's canonical URL.
DNS problemRouting checks against your custom domain have failed 3 times in a row, but your domain keeps serving your page normally for a 72-hour grace window while you fix the underlying problem. See Grace period below.
DisabledThe 72-hour grace window expired and your page fell back to the UptimeHunt endpoint. Remove and re-add the domain to start over.

Pending claims expire after 7 days

A domain left in Pending DNS, Ownership verified, or Certificate issued for more than 7 days without reaching Active is automatically deleted. If that happens, you'll need to re-add the domain and publish its DNS records from scratch.

Grace period

UptimeHunt continuously runs a routing check against your active custom domain (an HTTP token-echo check that confirms it still resolves to us). If that check fails 3 times in a row, your page enters a 72-hour grace period rather than dropping immediately — a single blip shouldn't take your custom domain down. During grace:

  • Nothing customer-visible changes. Your custom domain keeps serving your page normally, exactly as it did before — visitors still see it at your custom domain, not at <slug>.status.uptimehunt.io.
  • You have 72 hours for the platform to see the routing check succeed again (i.e. for you to fix the underlying DNS/routing problem).
  • Only if the 72 hours pass without the check recovering does your page fall back to <slug>.status.uptimehunt.io, and the domain moves to Disabled.

This grace period exists because your status page — the whole point of the feature — has to be the last thing standing. We won't let a transient DNS blip yank your custom domain out from under you; only a confirmed, sustained failure causes a customer-visible fallback.

Cloudflare proxy and SSL mode

If your domain is proxied through Cloudflare (the orange cloud icon), make sure you wait for the Let's Encrypt certificate to fully issue before enabling proxy. Once our certificate is live, set SSL mode to Full (Strict) so Cloudflare and UptimeHunt both speak HTTPS. Enabling proxy or downgrading SSL mode before the certificate issues can cause certificate conflicts or 525 errors.

On this page