How to set up a status page on your own domain

When your service goes down, every customer asks the same question: is it me, or is it you? Without a visible answer, they email support, post on social media, or assume you haven't noticed. A status page answers that question before they ask it.

This guide covers what belongs on a good status page, why it should live on a subdomain such as status.example.com, the DNS setup step by step, how to check it with dig, and how to use the page once an incident is under way.

Why publish a status page

First, it cuts the noise. During an incident, one public update replaces dozens of individual replies, and support can point everyone to a single address. It also builds trust between incidents: a day-by-day uptime history shows that you measure your service and have nothing to hide. Some prospects check it before they sign.

Internally, it keeps everyone on the same page. The salesperson on the phone and the support team read the same information at the same time. For a web agency, a status page per client, on the client's own domain, becomes part of the service you deliver.

What to put on the page

Components your users understand

Group your services into components the way users experience them, not the way they're deployed. Nobody knows what web-02 or redis-cache is; everyone understands "Customer dashboard". One component can combine several checks: the dashboard might rely on the login page and on the API behind it.

Three to eight components are enough for most products. Beyond that, the page gets hard to read at exactly the moment your users are worried.

Plain wording

Describe the impact as users feel it: "Some card payments are failing" means something to everyone, "Connection pool exhausted" to almost nobody. Always state the time zone of your timestamps. And use your customers' language: in LucidStack, each page can be shown in English or French.

Why use a subdomain like status.example.com

Three reasons favour a subdomain of your own domain name:

• Trust. Customers recognise your domain. A link to status.example.com in an email or support reply feels more trustworthy than a third-party address, and looks less like phishing.
• Independence. A status page hosted on your own servers goes down with your application. A CNAME to an external host keeps the page somewhere else while it still carries your name.
• Convention. status. is the prefix experienced users try first.

One limit to keep in mind: the subdomain still depends on your DNS servers. If the outage is your DNS provider, the page won't resolve under that name either. Keep a fallback channel (social media, email to customers) for that specific case.

Creating the CNAME record

A CNAME record declares that one name is an alias for another. You state that status.example.com is an alias of status.lucidstack.dev; the service then recognises your domain and serves your page. In LucidStack, custom domains are available from the Solo plan: add your domain in the status page settings first, then create the record.

In a zone file

; Zone example.com
status    3600    IN    CNAME    status.lucidstack.dev.

The trailing dot after status.lucidstack.dev. matters. Without it, the name is treated as relative to the zone and becomes status.lucidstack.dev.example.com, which doesn't exist.

In a DNS provider's dashboard

Most dashboards ask for the same fields under different labels:

Watch the Name field: many dashboards append your domain automatically, so typing status.example.com creates status.example.com.example.com. If your DNS goes through a proxy service (Cloudflare's orange cloud, for instance), set this record to "DNS only": an extra layer in between can get in the way of certificate issuance.

The apex domain caveat

You can't use example.com itself. A CNAME can't coexist with any other record on the same name (RFC 1034, section 3.6.2), and the apex of a zone always carries its SOA and NS records, plus your MX records. Some providers offer pseudo-records (ALIAS, ANAME, "CNAME flattening"), but a subdomain remains the simple, standard option with no surprises. The same rule applies to the subdomain: if it already has a TXT or MX record, remove it or pick another name.

Propagation and checking with dig

What "propagation" really means

DNS records don't really propagate. A new record is live on your authoritative servers immediately, and resolvers around the world pick it up as their caches expire, according to the TTL. A common trap: if you looked up the name before creating the record, resolvers cached the "this name doesn't exist" answer, for a duration set by your zone's SOA record (RFC 2308).

Checking the record

# Is the CNAME in place?
dig +short status.example.com CNAME
# Expected: status.lucidstack.dev.

# Full resolution, down to IP addresses
dig +short status.example.com

# Ask a specific public resolver
dig @1.1.1.1 +short status.example.com CNAME

# Ask your authoritative server directly
dig @ns1.your-dns-provider.example +short status.example.com CNAME

If the authoritative server answers correctly but your usual resolver doesn't, the setup is fine and you only need to wait for the cache to expire. If the authoritative server returns nothing, the record was entered incorrectly.

Automatic HTTPS

With LucidStack, the HTTPS certificate is issued automatically on the first visit. Once dig looks right, open the page yourself, so that you trigger the issuance rather than your first customer. If your domain publishes CAA records, they must allow the certificate authority in use, or issuance will fail. Then check:

curl -sI https://status.example.com | head -n 1

Subscribers, feeds and private pages

A page nobody visits informs nobody. Offer email subscriptions: in LucidStack they use double opt-in, and subscribers receive incident and maintenance announcements. RSS and Atom feeds suit feed readers as well as team chat tools that can follow them. An SVG badge can sit in your website footer, and a JSON summary feeds your internal tools.

Not every page needs to be public. A password-protected page works well for a key client, an internal team or a service in beta. For agencies, white label (logo, colours, custom CSS, no LucidStack branding) is available from the Agency plan.

Staying online during an outage

A status page has to survive the outage it reports. External hosting covers most of it; LucidStack also keeps a static copy of each page, refreshed every minute and served automatically if the application can't respond.

Two precautions on your side. If your custom CSS loads a font or image from your own servers, it will vanish along with them, so host those assets elsewhere. And monitor the record itself: a CNAME deleted during a zone clean-up makes the page disappear silently. DNS monitoring catches that kind of change.

Communicating during an incident

Post early, even without all the answers

The first message matters more than the diagnosis. In LucidStack, the incident appears on the page automatically once it's confirmed; add a few human words quickly:

Investigating, 14:05 UTC
Some card payments have been failing since 13:50.
Orders already confirmed are not affected.
Next update by 14:35 at the latest.

Keep a steady rhythm

Every update follows the same structure: the impact, what you're doing, and when the next update is due. Post at the announced time even if nothing has changed. Silence worries people more than "still investigating". When you're short on time, AI incident analysis can draft a public message for you to review before publishing.

Close it properly

Announce the resolution, how long the impact lasted and what comes next. For serious incidents, a postmortem published a few days later closes the loop. And announce maintenance ahead of time: subscribers get notified and nobody is caught off guard.

Setting up your page

Create the page, group your services into components, add your domain, then the CNAME record pointing to status.lucidstack.dev; the certificate follows on the first visit. LucidStack status pages include the 90-day history, subscribers, feeds and the backup copy. The Free plan includes one page, and custom domains start with the Solo plan, as shown on the pricing page.