# Status Pages on Your Own Domain & GDPR: What Agencies Should Know

> How to run a status page on your own domain via CNAME, where the data sits, and what to communicate cleanly under GDPR, the factual guide for agencies.

Source: https://uptimeify.io/blog/status-pages-custom-domain-gdpr

A status page on your own domain is one of the strongest trust signals an agency can send: `status.yourclient.com` shows at any moment that everything's running, branded, professional, no third-party logo. But the moment that page is publicly reachable under your domain, it becomes a website like any other in data-protection terms. **Custom-domain operation and GDPR therefore have to be thought through together**, one without the other leaves a gap that your client's data protection officer will eventually find. This article explains, factually, how the custom domain works via CNAME, which data sits where, and what can be communicated cleanly.

- **Custom domain via CNAME:** point a subdomain like `status.yourclient.com` via CNAME to the platform target, branded instead of a third-party address.
- **Two kinds of data:** the operational data shown (technical, not personal) and the visitor data on load (server logs, IP, embedded scripts).
- **Publicly reachable = privacy policy needed**, like any page under your domain.
- **Where the data sits:** at Uptimeify, EU-hosted, status data from EU-only polling. That shortens the GDPR classification.
- **Communicate factually:** where processing happens and who the controller is, no guarantee claims.

## The custom domain via CNAME: what happens technically

The visible difference between a strong and a weak status page is the address in the browser bar. Run the page under a generic provider URL and it looks outsourced; run it under `status.yourclient.com` and it's part of your, or your client's, brand. A single DNS record makes that possible: the CNAME.

A CNAME (Canonical Name) is a DNS record that points a subdomain to another address. In your domain's DNS, you declare that `status.yourclient.com` points to the target the monitoring platform gives you. From that moment the platform serves the content, but the visitor sees only your domain. The process is deliberately lean: pick a subdomain, create the CNAME, wait for propagation (usually minutes to a few hours), done.

At Uptimeify, status pages are built for exactly this: branded, on your own domain, either public or password-protected. The technical part is trivial. The part that deserves attention comes after: once the page is reachable under your domain, the same data-protection duties apply to it as to any other website you run.

The custom domain comes from a CNAME record pointing your subdomain to the platform target. Technically a three-liner, but from that moment the status page is, in data-protection terms, your page.

## What data a status page actually processes

To answer the GDPR question cleanly, you first have to separate which data is actually in play here. A status page processes two fundamentally different kinds, and only one of them is the usual pitfall.

**The operational data** is what the page displays: uptime figures, ongoing and past incidents, planned maintenance. That's technical status information about services, not personal data about your client's end users. This data is usually uncritical in privacy terms, because it identifies no one; it describes a server, not a person.

**The visitor data** arises only when the page is loaded. Whoever opens the status page leaves traces, as on any website: an IP address, server logs, possibly cookies. And here's the actual lever: everything you add on top comes with its own weight. An analytics script, an embedded font from an external server, a chat widget, each of these can trigger its own data processing, often into a third country. So the privacy-relevant part of a status page is rarely the status content, but what happens in the background on load.

Separate operational data (technical, not personal) from visitor data (IP, logs, embedded scripts). The status content is rarely the problem, what you add on top is.

## Where the data sits, and why that shortens the argument

The second question after "which data" is "where." And here the choice of platform decides whether your data-protection statement is a short or a long text. Two locations count: where the displayed data is stored and where it is collected.

At Uptimeify, both sit in the EU. The platform is EU-hosted, so the uptime and incident data the status page serves is stored within the European legal area. And the collection of that data, the actual checks, runs exclusively from European locations: Nuremberg, Falkenstein, Frankfurt, Berlin, Logroño, Paris, Warsaw, Milan, and Helsinki. There is no checking node outside Europe through which the status data would arise.

For your GDPR argument that means a noticeable shortening. The most laborious part of any data-protection assessment is the third-country transfer, processing outside the EU. When storage and collection of the status data happen entirely in the EU, that transfer never arises for the core of the status page. A long hypothetical about standard contractual clauses and government access becomes a short, verifiable statement. The only remaining construction site is then whatever you add yourself, and that's in your hands.

For the status data to stay in the EU, hosting and polling have to sit in Europe. See how Uptimeify's status pages run branded under your domain and with EU-hosted data.

## What you should communicate cleanly

Legal certainty doesn't come from a tool, it comes from clear communication. Once your status page runs publicly under your domain, the same mandatory disclosures belong with it as on any reachable website, and three points deserve special attention.

**Who is the controller?** If the page runs under `status.yourclient.com`, it should be recognizable to the visitor who operates the page and is responsible for the data processing, the agency, the client, or in which role each. You settle that internally in the data-processing arrangement and make it transparent externally via the imprint and privacy policy.

**Its own privacy policy.** A publicly reachable status page processes visitor data through server logs at the latest, and therefore needs a privacy policy, reachable from the status page. If you display only operational data and embed no external scripts, that text is short. Which is exactly why it pays to keep the page lean.

**Stay factual, don't guarantee.** Communicate where the data is processed, "EU-hosted, collection exclusively from European locations", as what it is: a verifiable fact. Avoid seal-style phrasing like "100% GDPR-compliant" or "legally watertight." Such claims age badly and don't hold up; the sober, factual statement is more credible and lasts longer.

Three mandatory points: name a clear controller, link your own privacy policy, state the processing location factually. No guarantee claims, the verifiable fact convinces more than the seal.

## Public or password-protected: a deliberate choice

One last point that touches both trust and privacy is the page's visibility. Uptimeify allows both modes, public or password-protected, and the choice should be made deliberately, per client.

A **public** status page is a transparency signal. Anyone can see the operational status, which radiates composure especially for services with many end users: showing a proactive public status during an incident reads as more composed than answering inquiries one by one. The price is that operational information is visible to everyone.

A **password-protected** page is the right call when the status information concerns only the client and their team, or when it allows conclusions about internal infrastructure that shouldn't be public. In privacy terms, access protection also narrows the visitor circle to authorized people. Which mode fits is a trade-off between transparency and confidentiality, and you make it best per client, not across the board.

In the end, a status page on your own domain isn't a pure design matter. It's a trust instrument that only carries fully when the privacy question doesn't stay open. Think the custom domain, the processing location, and the communication through together, and you get both: the strong brand signal and the calm, factual answer to the question that comes sooner or later.

Send the brand signal without leaving the privacy question open. See how Uptimeify's status pages run branded under your domain, public or password-protected, EU-hosted.