Moving the blog and status page to a new domain

On 2026-10-04 I moved the blog and the public status page under chrisalorenzo.com. The old hosts still answer, but they only redirect now. This post covers what changed, what I checked from outside, and what I got wrong on the first pass.

What moved

Thing	Before	Now
Blog	`stayz3ro.dev`	`blog.chrisalorenzo.com`
Public status page	`status.stayz3ro.dev`	`status.chrisalorenzo.com`
Status admin UI	reached over an SSH tunnel	tailnet-only Tailscale Serve path, loopback backend

The status page lives at /status/main, and the root of the status host redirects there. Admin paths return 404 from the public side. The admin UI itself stays on the tailnet.

The redirects

Old hostnames redirect with a 301, so search engines and bookmarks move with the content. Both stayz3ro.dev and www.stayz3ro.dev send requests to the blog with the path and query kept. The old status host sends its requests to the new one the same way.

Two things I got wrong on the first pass

Removing a custom domain deletes its DNS record. I removed the old blog hosts from the Cloudflare Pages project, and the removal deleted their DNS records with them. I had to put proxied, redirect-only records back before the rule could run at all.

Two host checks joined with AND match nothing. My first Redirect Rule compared the host to each old name with AND, which no request can satisfy. One comparison against both hosts, as a set, fixed it. The rule builder defaults to AND, so check the joins before saving.

What I checked from outside

These are plain GET requests on 2026-10-04, with certificate verification on and no redirects followed:

Request	Result
`https://chrisalorenzo.com/`	200
`https://blog.chrisalorenzo.com/`	200
`https://status.chrisalorenzo.com/`	302 to `/status/main`
`https://status.chrisalorenzo.com/status/main`	200
`https://status.chrisalorenzo.com/dashboard`	404
`https://status.stayz3ro.dev/`	301 to `https://status.chrisalorenzo.com/`
`https://status.stayz3ro.dev/status/main?stage=6`	301 to `https://status.chrisalorenzo.com/status/main?stage=6`
Both old blog hosts at `/`	301 to `https://blog.chrisalorenzo.com/`
Both old blog hosts at `/blog/domain-check?stage=6`	301 to `https://blog.chrisalorenzo.com/blog/domain-check?stage=6`

My local resolver could not resolve the old blog hosts at all. Public DNS-over-HTTPS answered, so I pinned those answers for the last two rows and kept the original hostnames for the TLS check. That proves the routing at the edge. It does not prove that my local resolver has recovered, so I will recheck ordinary resolution once caches expire.

What is still open

The monitoring side is not finished. The live Blog, public-status-edge and HTTPS Edge monitor targets still need to be confirmed against the new hostnames. A blog-redirect monitor, which checks that the old blog URL still returns the 301, is not in place yet. Certificate-expiry notices stay on. Those are the Stage 6 items, and I am not calling them done.

Where the earlier posts fit

The August status page post describes how Kuma was first deployed on the old hostname and how its admin was claimed over a tunnel. That is still accurate as history. The current route is described in the note at the top of that post and in its closing section.