---
title: "Expired Domains Vanished From Every Account Page Until June 23"
canonical: https://dxdev.com/blog/visible-deleted-state-recovery/
datePublished: 2026-06-23
---
At 6:44 PM on June 23, we stopped treating a removed domain as if it had never existed.

Before that, an expired domain simply vanished from the screen. The customer saw no domain. Staff search saw no domain. The detail page offered no explanation and no recovery path. Everyone was left asking the same question: where did it go?

The record was never gone. The product had hidden it, and we had a hand in building the product that hid it. Every customer who hit this before June 23 was told, in effect, that their domain had disappeared. The cause was a filter on a query that we had treated as the truth about what still existed.

## What the account looked like versus what it was

The diagnostic path started with the two surfaces that matter when something leaves an account: the account detail page and staff search. The expired domain was missing from both. With both views empty, nothing in the product showed the account had ever had that domain. A current-state query is happy with that. A customer trying to understand a change is not, and neither is a staff member trying to fix one.

What it looked like was an account with no domain. What it actually was was an account with a domain record in an expired state.

Those two states call for different responses. The first invites a new setup flow. The second needs an explicit recovery action.

So the removed domain now stays on the detail page, struck through, instead of being filtered out. It stays in staff search too. Next to it sits one action that says exactly what will happen: re-activate.

The detail that matters in the implementation is that re-activation reuses the same record. We do not create a replacement record that happens to contain the same domain. We restore the one the account already had. That keeps the history coherent, and it keeps the workflow honest, because the customer is recovering something the system can still see instead of starting over.

## Why the other options fell short

Hard deletion was the simplest to explain in code: when a domain expires, delete the row and let the account read as empty. It loses at once, because nothing is left to recover. The system would have to reconstruct an identity it had just thrown away.

Keeping the record but hiding it from every customer-facing surface is better for internal retention, but it does nothing for the person looking at the account. It turns an ordinary account state into a support investigation. Staff can dig up an archived record somewhere, while the customer gets no hint that reactivation is possible.

Creating a new record on reactivation avoids an explicit state transition, but it gives the wrong model. An expired domain is the same domain. The existing record is the object whose state changed, so reusing it is simpler and more accurate.

The struck-through presentation is deliberate. It separates expired from active without making the record disappear. On screen it says the domain is no longer active, and it does not say the domain has been erased from the account's history.

## The report became a cleanup queue

The customer and staff views solve the immediate recovery problem. The staff Domain Report needed a different change, so we converted it into a renewal and cleanup view that defaults to expired sites.

That default turns the report from a broad inventory screen into a queue of work that needs attention. It also flags Rookie and Pro accounts that are still carrying a platform-managed domain. Expiration is not the only condition worth finding. A lower-tier account with an active managed domain is a separate cleanup decision, and it should not be buried in a report built around active sites.

The sequence now has a shape we can reason about:

1. A domain expires, but its record remains available.
2. The account detail page and staff search show that record as inactive.
3. Re-activate restores the same record instead of creating another one.
4. The staff report defaults to the expired work and identifies tier mismatches that need review.

The remaining work is deliberately separate. We still need domain-aware expiration emails, then a careful bulk catch-up for existing records. Neither belongs in the first change. The first change makes the current state visible and reversible. That gives us a safe base for communicating expiration and repairing the backlog without asking staff or customers to infer what disappeared.

## Check your own account page

Deleted is a data operation. Expired is an account state. If your system keeps expired records, open an account that has one and look at the detail page and at staff search. If the record is filtered out of both, it looks gone. In our case the record was still there, and hiding it made a recoverable state look like permanent loss.