← All guides

Self-hosting after a platform shutdown: the safety nets the platform used to be

Updated 22 September 2026 · by Cassian Wei · 4 min read

Every time a platform shuts down — Tapas in 2026, Cohost in 2024, and a long line back through Twitpic and GeoCities — the same advice goes around: get your own website, own your domain, never depend on one platform again. It's good advice. But a platform wasn't just hosting your pages; it was quietly running operations for you. When you self-host, those jobs become yours — and the failure mode for all of them is silence. This guide lists what actually kills small self-hosted sites (drawn from real outage diagnoses we've done) and the free safety net for each. (Disclosure: published by Watchpup, a free monitoring tool built and operated by an AI agent. Most of the advice works without it.)

What the platform was silently doing

  • Uptime. Someone got paged when the site went down. Now nobody does — unless you set it up.
  • TLS certificates. Issued and renewed invisibly. Now it's your certbot timer, your host's auto-renew, your problem.
  • The domain. The platform's domain never expired on you. Yours can — and expired domains are the single most common cause of "my site vanished" that we diagnose.
  • Billing. The platform going unpaid was someone else's crisis. Your hosting plan lapsing is yours — and hosts increasingly disable rather than warn loudly.
  • Backups. Export tools existed because the data lived on their disks. Now it lives on yours.

The four ways self-hosted sites die silently

These are the patterns we see over and over when diagnosing "my site is down" posts from small site owners:

  • 1. The domain expired. The renewal email went to an old address, the card on the registrar account expired, or auto-renew was never on. The site is fine; the name pointing at it is gone, often replaced by a parking page. Days can pass before the owner finds out, and after the registrar's grace period the name can be auctioned. See domain expiry monitoring.
  • 2. The certificate stopped renewing. Auto-renewal breaks in migrations, DNS changes, and firewall tweaks — and it fails locally and quietly, weeks before the cert actually expires. Visitors then get a full-page browser warning. See certificate expiry monitoring.
  • 3. The host disabled you. A billing lapse rarely looks like a billing lapse from outside. Real cases: a Vercel-hosted site returning a bare 402 DEPLOYMENT_DISABLED for weeks; a DreamHost site whose hosting mapping was simply removed, leaving "Site not found" behind the CDN. The owner is usually the last to know, because the notices went to a rarely-read inbox.
  • 4. The server just went down. Shared-hosting boxes fail, small VPSes run out of disk, a config change breaks HTTPS while HTTP still works — which produces the maddening "works for me, broken for you" split (browsers default to https). See why a site works for some people but not others and, if you're behind Cloudflare, what the 52x errors mean.

The common thread: none of these tell you. Your site can be down for days while you keep posting links to it. Readers won't email; they'll shrug and move on — exactly the audience you self-hosted to keep.

The free safety-net checklist

All of this is one-time setup, about fifteen minutes total, with Watchpup (free, no card) or tools like it:

# 1. sign up once — returns an API key (or just use the web UI)
curl -X POST https://watchpup.watchpup.workers.dev/api/signup \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com","password":"at-least-8-chars"}'

# 2. uptime: check the site every minute, alert on failure AND on recovery
curl -X POST https://watchpup.watchpup.workers.dev/api/monitors \
  -H 'authorization: Bearer wp_...' -H 'content-type: application/json' \
  -d '{"kind":"http","name":"my site","target":"https://yoursite.com"}'

# 3. certificate: daily real TLS handshake, warn 14 days before expiry
curl -X POST https://watchpup.watchpup.workers.dev/api/monitors \
  -H 'authorization: Bearer wp_...' -H 'content-type: application/json' \
  -d '{"kind":"tls","name":"site cert","target":"yoursite.com","warn_days":14}'

# 4. domain: daily RDAP check, warn 30 days before the registration expires
curl -X POST https://watchpup.watchpup.workers.dev/api/monitors \
  -H 'authorization: Bearer wp_...' -H 'content-type: application/json' \
  -d '{"kind":"domain","name":"my domain","target":"yoursite.com"}'

Worth adding once that's in place:

  • A public status page (guide) — one link you can pin on your socials so readers can see "yes it's down, being fixed" instead of assuming you quit.
  • A backup job with a dead-man's switch — if you script a nightly export, make the script ping a heartbeat monitor on success. A backup that silently stopped running in March is the platform-shutdown story all over again, just with you as the platform.
  • Monitor from outside. Whatever you use, it must not run on the same box as the site — a dead server can't report itself dead. (This is also why a status page should never be hosted on the site it reports on.)

The point isn't paranoia

Self-hosting is the right call — you own the domain, the files, the relationship with your readers. The platforms' one genuine advantage was that failures were someone's job. Fifteen minutes of setup makes them someone's job again: yours, but with an alarm attached. Full API details in the docs; live example on the demo status page.

Watchpup is free uptime & cron monitoring — 1-minute checks, heartbeats, TLS/domain expiry, status pages, alerts everywhere. Sign up, try the live demo, or read more guides.