Can I use my main domain for the status page, without a subdomain?

Not with a CNAME, because the apex of a zone already holds SOA and NS records and a CNAME cannot sit next to other records. Some DNS providers offer ALIAS, ANAME or CNAME flattening to work around this, but your status page provider must support it, and it means giving up the apex for your main site. A subdomain is simpler.

How long does it take for a custom status page domain to work?

Usually a few minutes after the CNAME record is published, plus the time the provider needs to validate the domain and issue a certificate. If you previously had a different record at the same name with a long TTL, resolvers may keep the old answer until it expires.

Should the status page be on a different provider from my website?

Yes. The page is most needed when your own infrastructure is down, so it should not share servers, hosting accounts or load balancers with the product. DNS is the one dependency they share, which is another reason to monitor your DNS records.

Do I need to buy an SSL certificate for the status page?

Usually not. Hosted status page providers issue and renew a certificate for your custom domain automatically once the DNS record points to them. You only need to make sure CAA records, if you have them, permit the certificate authority they use.

How to Put Your Status Page on Your Own Domain (status.yourcompany.com)

To put your status page on your own domain, pick a subdomain such as status.yourcompany.com, add a CNAME record for it at your DNS provider pointing to the host name your status page provider gives you, and wait for the provider to detect the record and issue an HTTPS certificate. Use a subdomain rather than the bare domain, because the apex of a zone cannot be a CNAME. If your DNS is on Cloudflare, set the record to DNS only rather than proxied. If your domain has CAA records, they must allow the certificate authority your provider uses. That is the whole job for most setups; the rest of this guide covers why it is done this way and how to fix it when it does not work.

Why a separate subdomain

A status page on status.yourcompany.com does three things a provider's default address does not:

People can find it under pressure. "status dot our domain" is easy to guess and easy to say on a support call.
It looks like yours. Customers are more likely to trust an update on your own domain than on an unfamiliar third-party address.
You can link it everywhere without exposing which vendor you use: app error pages, help center, API documentation, email footers and automatic support replies.

The subdomain also keeps the status page separate from your main site in DNS. Changing where status points never touches the records for www or the apex.

Why a separate provider

A status page exists for the moments when your product is down. If it runs on the same server, the same hosting account or behind the same load balancer as the product, it fails at the same time. Host it with a provider that has nothing to do with your main infrastructure.

There is one dependency you cannot remove: your DNS. If your DNS provider fails or the domain expires, status.yourcompany.com fails along with everything else. Keep the provider's own address (for example acme.pingrobot.io) bookmarked and mention it in your incident runbook as a fallback, and watch the domain itself with a domain expiry reminder and DNS monitoring.

CNAME vs A record vs ALIAS

CNAME: the normal choice

A CNAME record makes one name an alias for another. Your status page provider gives you a target host name, and you create:

status.yourcompany.com.   300   IN   CNAME   statuspage-target.example.net.

The provider can change the IP addresses behind its host name at any time without you editing anything. That is why most hosted status page services ask for a CNAME.

Why the apex cannot be a CNAME

The bare domain (yourcompany.com) is the apex of the zone. It always has SOA and NS records, and the DNS rules (RFC 1034) do not allow a CNAME to coexist with any other record at the same name. Most DNS providers simply refuse to save one there.

A records

An A record points a name at a fixed IPv4 address. Some providers support this for apex domains, but it breaks if they ever renumber, so many hosted services do not offer it. Check your provider's documentation before you use one.

ALIAS, ANAME and CNAME flattening

Some DNS providers have a non-standard record type, often called ALIAS or ANAME, or a feature called CNAME flattening, that behaves like a CNAME at the apex by resolving the target and publishing its addresses. It works for some services, but the provider issuing your certificate may not be able to validate it. Unless you have a strong reason, use a subdomain and a plain CNAME.

Step by step

In your status page tool, enter the custom domain, for example status.yourcompany.com, and note the target host name it shows.
At your DNS provider, create a CNAME record. The "name" field is usually just status; some providers want the full name. Point it at the target.
Remove conflicting records at the same name. You cannot have a CNAME and an A, AAAA or TXT record on status at the same time.
Check the record from a public resolver:

dig +short CNAME status.yourcompany.com @1.1.1.1

Wait for validation and the certificate. The provider checks that the record points to it, then issues a certificate. This is usually automatic.
Open the page over HTTPS and confirm the certificate covers the right name:

curl -sI https://status.yourcompany.com
echo | openssl s_client -connect status.yourcompany.com:443 -servername status.yourcompany.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -dates

Update your links in the app, docs and support templates.

For PingRobot specifically (custom domains are a Pro feature), the exact record and settings are in the status page domain docs.

Cloudflare: DNS only vs proxied

If your domain's DNS is on Cloudflare, each record has a proxy toggle. With it on (the orange cloud), Cloudflare answers with its own addresses, terminates TLS itself and forwards requests. That gets in the way of a status page provider that needs to see the CNAME, validate the domain and serve its own certificate.

Set the status record to DNS only (the grey cloud) unless your provider explicitly tells you to proxy it. Check what the public sees:

dig +short status.yourcompany.com @1.1.1.1

If you get Cloudflare IP addresses instead of the CNAME target, the record is still proxied.

Certificates and CAA records

Hosted providers issue certificates through a certificate authority, often Let's Encrypt or Google Trust Services. CAA records (RFC 8659) restrict which authorities may issue for your domain. CAA records on the apex normally apply to subdomains too, because an authority that finds none at status.yourcompany.com looks at the parent domain next.

List them:

dig +short CAA yourcompany.com @1.1.1.1

If the result is empty, any authority may issue and there is nothing to do. If there are entries, make sure the one your provider uses is included, for example:

yourcompany.com.  3600  IN  CAA  0 issue "letsencrypt.org"
yourcompany.com.  3600  IN  CAA  0 issue "pki.goog"

Ask your status page provider which authorities it uses if the docs do not say.

Common errors and what they mean

Symptom	Likely cause	Fix
Provider says the record was not found	Record not saved, typo in the target, or still cached	`dig` the name; lower the TTL next time
Record exists at `status.yourcompany.com.yourcompany.com`	The DNS panel appended the domain to a full name you typed	Enter only `status` in the name field
Browser shows a certificate warning	Certificate not issued yet, or CAA blocks issuance	Wait a few minutes, then check CAA
Page shows your main site or a parking page	An old A record or wildcard is still answering	Remove the conflicting record
Cloudflare error page	Record proxied	Switch to DNS only
Works for you, not for others	Resolver caches holding the old answer	Wait out the old TTL
Stopped working months later	Domain or plan lapsed, or record deleted during a DNS cleanup	Monitor the record and the domain

After it works

Treat the custom domain as production infrastructure:

Monitor it. An HTTP monitor on https://status.yourcompany.com and a DNS monitor on the CNAME catch a deleted record or a certificate problem before customers do.
Document it. Note the record, its purpose and who owns it, so nobody removes it as "unused" during a DNS cleanup.
Keep the fallback address handy, in case your own DNS is the thing that is broken.

For what to put on the page once it is live, see what a status page is and what to put on it and how to create a status page.

Start monitoring free — 10 monitors, no credit card.