Custom status page
Logdash gives you two kinds of custom status page: the hosted page on your own subdomain through one CNAME to statuspage.logdash.io on Pro, or a page you build yourself on the public API, on any domain and any plan.
"Custom" means one of two things. Either the page lives on your domain, so customers see status.yourapp.com instead of a vendor URL. Or the page looks like your product, in your fonts and colours. Logdash does both, by two different routes: the domain on Pro, the design on every plan.
Status page custom domain: the hosted route
On Pro, open the status page in Logdash, enter a subdomain such as status.example.com and add one DNS record. Logdash looks for it every 5 seconds. Once the CNAME points at statuspage.logdash.io, the domain is verified, the page is served there over HTTPS, and the status page API accepts the domain in place of the id.
# The record, in any DNS provider
# Type Name Target
# CNAME status statuspage.logdash.io
# Check it from your machine before Logdash does
dig +short CNAME status.example.com
# statuspage.logdash.io.Verification gives up after 60 attempts, about 5 minutes. If the record was not there in time, the domain is marked failed: fix the DNS, delete the domain and add it again. On the hosted page you choose its name and which monitors it shows. Fonts, colours and layout are fixed.
Cloudflare custom status page
If your DNS is on Cloudflare, create the record as DNS only, the grey cloud. A proxied record answers with Cloudflare IP addresses, so the CNAME lookup never sees statuspage.logdash.io and verification fails. Paid zones can also flatten every CNAME, so check that setting is off. If you would rather build the page on Cloudflare itself, cf-workers-status-page is the known open source option, though it has not had a commit in about three years.
Custom design: the build-your-own route
Every published page is also JSON at the public status page API, with no key, on every plan. The quickest way to render it is the shadcn component, which takes your Tailwind theme through the shadcn CSS variables:
npx shadcn add https://logdash.io/r/react/status-page.jsonDeploy the result anywhere, on any domain. Logdash never needs to know which one, so this is also the way to a custom domain without Pro. For a complete site, the Next.js starter deploys to Vercel in one click. Either way, host it apart from your app: a page that shares servers or DNS with the app goes down with it.
Which route to pick
Pick the hosted route when the page just needs to exist and you are already on Pro: one record, nothing to deploy, nothing to update. Pick your own build when the page is part of your brand, when you want status inside your app, or when you are on the free or Builder plan. Both read the same checks, so you can start hosted and move to your own build later without losing a day of history.
Logdash vs Uptime Kuma
| Feature | Logdash | Uptime Kuma |
|---|---|---|
| Your own domain | Pro plan, one CNAME | Free, through your reverse proxy |
| HTTPS on that domain | Handled by Logdash | Your reverse proxy and certificate |
| Custom design | Any design through the API, component or starter | Custom CSS on the Kuma layout |
| Incidents and maintenance | None | Both built in |
When Uptime Kuma is the better pick
- You want the hosted page on your own domain for free and already run a reverse proxy.
- You post incidents and maintenance notices. Logdash pages show checks only.
- Monitoring has to stay inside your own network.
Set it up
- Pick a route Hosted page on Pro with one CNAME, or your own build on any plan, including the free one.
- Point DNS CNAME the subdomain to statuspage.logdash.io, DNS only on Cloudflare, or to wherever you deployed your own build.
- Test the alert Connect Telegram, then stop one monitored service. Your status subdomain shows it within a few minutes, but the Telegram alert reaches you first, with the monitor name and status code.