Behind the Scenes: Implementing Custom Domains

The visible feature is only the last step

Custom domains are one of those features that appear simple when they work well. An agency adds a domain, points DNS at the service, and a status page begins to load at an address that belongs to the agency.

That final result is important. It makes the status page feel like part of the service the client already trusts. But getting there safely requires more than accepting a hostname in a form.

We needed a flow that could verify domain ownership, give useful DNS instructions, wait for propagation, provision a certificate, and route traffic to the right status page without creating a fragile operational dependency.

DNS has to be explicit

The first requirement is proving that the person adding a domain can control it. A custom-domain system should not allow someone to route another organization's domain into a status page.

Leoric Watch uses DNS verification as the ownership check. The workflow guides the account owner to add the required record, then verifies that the expected value is visible before the domain can become active.

DNS does not update everywhere at once, so the product also needs to make the waiting state clear. A domain can be correctly configured and still take time to propagate. Clear verification status and retry behavior matter because they turn a confusing infrastructure delay into a manageable setup task.

HTTPS cannot be an afterthought

Once a domain is verified, visitors expect it to load securely. That means the platform needs to request, install, and renew TLS certificates automatically.

Certificate management is easy to overlook because it is invisible when it works. It becomes very visible when it fails. We designed the flow so certificate issuance is tied to verified domain ownership and the status page does not claim to be ready before HTTPS is available.

The ongoing work is just as important as the first issuance. Certificates expire, DNS records change, and domains can be removed or reassigned. The system has to track those states and make recovery understandable for the account owner.

Routing needs a clear source of truth

A request reaching a custom domain needs to resolve to exactly one published status page. That mapping has to be fast and predictable, but it also has to respect account ownership and publishing state.

We keep the custom-domain configuration close to the status page profile it represents. That gives the application a single source of truth for the hostname, verification state, and public destination. The edge layer can then route an incoming hostname to the right page once the platform has confirmed that it is active.

This separation is intentional. DNS and certificate details belong in the setup lifecycle; the public status-page request should remain quick and uncomplicated.

The point is a more credible client experience

Custom domains are not only a branding feature. During an incident, they create a recognizable place where clients can find information without wondering whether the page is legitimate or current.

That confidence is the real value. The implementation should disappear into the background so the agency can focus on the update it needs to share.

See how Leoric Watch supports agency status pages.