Running twelve domains from one control tower

For about three years the honest answer to “how do you keep twelve domains running?” was: nine browser tabs, two terminals, a Notes file, and a bad feeling. It worked in the sense that nothing catastrophic happened. It did not work in the sense that I could not tell you, at any given moment, which certificates were about to lapse or which Stripe webhook had been quietly failing since Tuesday.

The fix was not a new tool. It was deciding what deserved a screen.

The rule I settled on

Anything I check more than twice a week gets a tile. Anything I check less than that gets an alert instead. That single rule collapsed a sprawling wish-list into six tiles, and the six tiles are what the control tower actually shows:

• Domain and certificate health — expiry dates for every property, sorted by days remaining
• Deploy state — last successful build per repo, with the commit and who (or what) authored it
• Payments — Stripe webhook failures and subscription churn for the week
• Subscriber flow — new signups per property, so a broken form is visible within a day
• Agent activity — what my coding agents touched, and what is waiting on review
• Inbound — calls the AI receptionist handled and the ones it escalated

A dashboard is not a place to put everything you can measure. It is a place to put the six things that would ruin your week if they broke silently.

What I refuse to automate

Agents write most of the code in this network now. They do not get to press the button on three things: DNS cutovers, price changes, and anything that sends email to the full subscriber list. Not because they would do it badly — because the failure mode is unrecoverable and the time saved is trivial. A DNS change takes ninety seconds of my attention and can take a masthead offline for a day.

Everything else is fair game. Dependency bumps, preview deploys, content migrations, invoice reconciliation drafts, brand-kit regeneration — all of it happens without me, and I read the diff.

The readiness check

The single highest-value thing I built was not the dashboard. It was a pre-cutover readiness check that runs before any domain points at new infrastructure. It is unglamorous and it has saved me four separate outages:

readiness checklist
  ├── DNS: target resolves, TTL lowered, old record noted
  ├── TLS: cert issued and chain valid on the new origin
  ├── redirects: legacy URL map returns 301, not 404
  ├── sitemap: submitted, and the old one still served
  ├── webhooks: Stripe + Twilio endpoints re-pointed
  └── rollback: previous config saved, one command away

Six lines. It is the difference between a migration and an incident.

What actually changed

Time spent on operations dropped, but that is not the interesting part. The interesting part is that I started shipping things I had been avoiding — the invoice manager, the receptionist, a second society magazine — because the overhead of adding another moving part stopped feeling dangerous. Reducing operational anxiety is a feature. It shows up as output.

The tower is boring now. That is the whole point.