Status page slug rules

The slug is the trailing path segment of your status URL: domaincare.io/status/<slug>. It also identifies your page in the admin UI.

Format

^[a-z0-9](?:[a-z0-9-]{1,30}[a-z0-9])?$

• Lowercase a–z, digits 0–9, and the hyphen -.
• Three to thirty-two characters total.
• No leading or trailing hyphen.
• No underscores, dots, or capitals.

Reserved set

The following are blocked at v1 to leave room for product surfaces:

api, app, www, admin, dashboard, docs, blog, mail, status, support,
help, account, billing, settings, public, incidents

incidents is reserved because domaincare.io/status/incidents/<id> is the dogfood incident detail route. Attempting to claim any reserved slug returns 400 { error: "slug_reserved" }.

Uniqueness and reclamation

Slugs are globally unique among live pages. The Postgres unique index is partial: WHERE deleted_at IS NULL. That means deleting a page frees its slug for reuse the moment the row is soft-deleted.

A daily Inngest job (status-page-slug-reclamation) at 04:00 UTC soft-deletes pages that meet all of:

• Never published (published_at IS NULL).
• Older than 30 days (created_at < now() - INTERVAL '30 days').
• Quiet for 30 days (last_activity_at < now() - INTERVAL '30 days').

Any builder edit — drag, config change, page rename — bumps last_activity_at, so an actively maintained draft is never reclaimed.

If a slug you wanted is taken, you have three options:

1. Pick a different slug.
2. If it's your own dormant draft, delete it explicitly via the API: DELETE /api/status-pages/:id.
3. Wait — if the page is dormant, the daily reclamation job will free the slug at the 30-day mark.

Org slug vs page slug

The slug attached to your organization (used in the in-app URL) and the slug attached to a status page are independent. We deliberately don't auto-reuse the org slug, because:

• Multiple status pages per org would collide.
• Many org slugs are not appropriate for a public surface.
• The reserved-set rules differ — we don't reserve org slugs.