So bereiteten wir eine Shared-Hosting-Website mit Cloudflare Workers auf die Serverwartung vor

Die Wartungsankündigung nannte ein sechsstündiges Fenster, aber keine genaue Ausfallzeit. Eine Down-Mail abzuwarten hätte eine manuelle Lücke erzeugt; eine einzelne Wartungsseite hätte zwar informiert, aber weder Inhalte noch Browser-Tools erhalten.

Hier dokumentieren wir die tatsächlich eingesetzte Lösung: Host-Ticket, Entscheidungslogik, Snapshot, Same-Zone-Falle, Free-Plan-Schutz, SEO, Werbung, Analytics und ehrliche Grenzen.

Zeitlicher Hinweis: Am 18. Juli 2026 hat die geplante Wartung noch nicht stattgefunden. Die Ergebnisse stammen aus erzwungenen Origin-Fehlern, privatem Staging, vollständigen Snapshot- und gesundem Live-Pass-through-Test, nicht aus dem echten Wartungsfenster.

Was das HostArmada-Ticket geklärt hat

Das Wartungsfenster war für den 22. Juli 2026 von 10 bis 16 Uhr CDT angesetzt. Wir fragten nach realer Ausfalldauer, temporärer Migration, betroffenen Diensten, einem externen 503-Endpunkt für jede URL, Rollback und möglicher Gutschrift.

Nach Eskalation erklärte die Administration: Sechs Stunden waren das reservierte Fenster, nicht sechs garantierte Stunden Downtime. Der tatsächliche Ausfall sollte kürzer sein, ließ sich wegen Hardwarearbeiten, Systemupdates und Prüfung aber nicht exakt vorhersagen. Ein Hin-und-zurück-Umzug des Kontos galt wegen DNS-, Datei-, E-Mail- und Datenbank-Synchronisation nicht als sicherere Lösung.

HostArmada bot vernünftig an, auf einem nicht betroffenen Server einen temporären Virtual Host mit Wartungsseite einzurichten. Wir hätten den A-Record zu Beginn manuell umstellen und danach zurückstellen müssen. Externes DNS würde weiter auflösen, Web, Datenbank, E-Mail und Control Panel des betroffenen Servers wären jedoch nicht erreichbar. Backups und Wiederherstellungsverfahren bestanden; eine Gutschrift sollte nach dem realen Einfluss geprüft werden. Das war eine faire Wartungsseiten-Lösung, aber weder automatisch noch funktionale Site-Kontinuität.

That offer was fair for a maintenance notice. It was still manual and did not provide functional-site continuity, so we used it as the baseline to improve rather than portraying it as a provider failure.

Belegbare Zeitachse: von der Wartungsmail zur getesteten Kontinuität

Die Chronologie trennt Provider-Ankündigung, unsere Fragen, den tatsächlich gebauten und getesteten Stand sowie das noch ausstehende reale Wartungsereignis.

1. Juli 2026 — Wartungsmail

   Die Start-Dock-Shared-Hosting-Mail reservierte den 22. Juli, 10–16 Uhr CDT. Genannt wurden CPU-, RAM- und SSD-Upgrades, Webserver-Sicherheits-/Softwareupdates, Kernel-Update, tmp/cache/log-Bereinigung und allgemeine Optimierung; nach Start sei der Vorgang nicht reversibel.

2. 16. Juli — Fragen eskaliert

   Wir fragten nach echter Downtime, Migration, externem 503, betroffenen Web/DB/E-Mail-Diensten, Backup, Rollback und Gutschrift.

3. 17. Juli — HostArmada antwortet

   Sechs Stunden seien das Fenster, die Unterbrechung voraussichtlich kürzer, ein Account-Umzug wegen Synchronisation riskant; angeboten wurde ein vHost plus manueller A-Record-Wechsel.



4. 17. Juli Design gewählt; 18. Juli Follow-up gesendet

   Always-on Origin-first Worker, statischer Snapshot, privates Staging, Kollisionsprüfung, definierte 503 und eigener Rollback.



5. 17.–18. Juli — kontrolliert umgesetzt

   1.514 Seiten und 1.234 Assets erfasst, 2.748 Pfade auditiert, Fehler/Pass-through getestet, Same-Zone-Rekursion behoben und Apex/www fail-open aktiviert.

6. 18. Juli — vorbereitet, Ereignis ausstehend

   Die Schicht ist live und getestet; die Wartung am 22. Juli ist noch nicht erfolgt. Reale Event-Dauer, Traffic und Umsatz brauchen Nachmessung.

Architektur: Origin zuerst, Snapshot nur bei Bedarf

Der Worker liegt dauerhaft auf Apex- und www-Route. Er fragt den echten Origin mit begrenztem Timeout ab. Eine gesunde Antwort wird unverändert weitergereicht; PHP, Sessions, Header, Werbung und Analytics bleiben normal.

Bei Netzwerkfehler, Timeout oder Status 500, 502, 503, 504 beziehungsweise Cloudflare 520–527 sucht er denselben Pfad im Snapshot. GET und HEAD bleiben verfügbar. Jeder spätere Request prüft den Origin erneut, daher erfolgt die Rückkehr automatisch.

Der Snapshot ist bewusst kein zweiter PHP-Stack. So entstehen keine zwei beschreibbaren Datenbanken, Sessionkonflikte oder nachträgliche Datenabgleiche.

Request-Ablauf im Überblick

Automatische Origin-RecoveryJeder spätere Request testet den Host; eine gesunde Antwort läuft sofort durch.

Provider-Wartungsseite oder Worker-Kontinuität?

Beides ist sinnvoll: Eine Wartungsseite liefert korrekte Semantik mit wenig Vorbereitung; ein Snapshot hält dagegen die meisten lesenden Wege und clientseitigen Tools benutzbar.

Was Nutzer und Crawler im Fehlerfall erhalten

Öffentliche Seiten, Browser-Tools, CSS, Skripte, Bilder und Fonts kommen aus dem Snapshot. Ein kleiner Hinweis kennzeichnet den reduzierten Betrieb; Canonicals und strukturierte Daten bleiben auf der Original-URL.

POST und nicht verfügbare Aktionen täuschen keinen Erfolg vor: Sie antworten mit 503 Service Unavailable, Retry-After: 300 und Cache-Control: no-store. RFC 9110 beschreibt 503 ausdrücklich für vorübergehende Überlastung oder geplante Wartung.

This distinction matters: returning a pretty 200 OK “maintenance” page for a failed form can mislead users and crawlers. Returning a controlled 503 for the unavailable action is both more honest and easier for clients to retry.

Tatsächliche Fallback-Matrix

Snapshot-Build und Verifikation

Wir crawlten die gerenderte Live-Site statt des lokalen PHP-Baums, weil dort unveröffentlichte Änderungen lagen. Erfasst wurden 1.514 gerenderte Seiten und 1.234 referenzierte First-Party-Assets. Das Paket enthielt 2.749 Dateien mit rund 547,6 MB; jede blieb unter Cloudflares Dateigrenze.

Canonical- und Schema-Markup blieben erhalten. Tracker wurden beim Snapshot entfernt; nur der Produktions-Worker fügt GA4, AdSense und Clarity auf der Startseite verzögert hinzu. Das private Staging bleibt trackerfrei und noindex.

Die QA umfasste TypeScript- und Unit-Checks, simulierten Origin-Ausfall, authentifiziertes Staging, Browser- und Origin-Preview-Tests sowie ein vollständiges Remote-Audit: alle 2.748 öffentlichen Seiten- und Assetpfade waren erfolgreich.

Privates Staging vor öffentlichen RoutenAuthentifizieren, noindex setzen, Fehler erzwingen, Origin vergleichen, freigeben.

Sicher nachbauen: Schritte und bereinigte Codebeispiele

1. Vertrag definieren. Hosts, sichere Methoden, Fehlerstatus, Timeout, unbekannte Pfade und Routen-Rollback festlegen. Nicht jede Nicht-200-Antwort ist ein Ausfall.

2. Gerendertes Production crawlen. Von der kanonischen Sitemap nur Same-Origin-Ressourcen aus HTML/CSS sammeln, URLs normalisieren, Traversal blockieren und bei Datei-/Größenlimit hart abbrechen.

3. Bedeutung erhalten. Canonical, hreflang, Schema, Links und Browser-Tool-Assets behalten; Service Worker und Tracking aus der Kopie entfernen. Ads/Analytics erst im Production-Worker injizieren.

4. Assets binden. ASSETS mit run_worker_first verwenden, damit zuerst der Origin geprüft wird. Die Beispiele nutzen ausschließlich Platzhalter.

5. Same-Zone-Schleife vermeiden. Einen kontrollierten DNS-only-Namen derselben Zone für resolveOverride nutzen, URL und Host kanonisch lassen und TLS/vHost direkt prüfen.

6. Privates Staging. Secret, noindex, blockierendes robots, keine Werbung/Analytics und expliziter Origin-Vergleich.

7. Routen einzeln anhängen. Kollisionen ablehnen, Apex prüfen, dann www samt Redirect; fail-open nur für einen Verfügbarkeits-Worker.

8. Rollback entkoppeln. Nur die eigenen Routen entfernen; Worker/Snapshot behalten und temporäre Edit-Rechte danach widerrufen.

{
  "name": "example-host-outage-fallback",
  "main": "src/index.ts",
  "compatibility_date": "2026-07-17",
  "assets": {
    "directory": "./snapshot/dist",
    "binding": "ASSETS",
    "run_worker_first": true,
    "html_handling": "none",
    "not_found_handling": "none"
  },
  "vars": {
    "MODE": "production",
    "ORIGIN_BASE": "https://example.com",
    "ORIGIN_RESOLVE_OVERRIDE": "origin-bypass.example.com",
    "ORIGIN_TIMEOUT_MS": "4500"
  }
}

const FALLBACK_STATUSES = new Set([
  500, 502, 503, 504, 520, 521, 522, 523, 524, 525, 526, 527
]);

try {
  const origin = await fetch(originRequest, {
    signal: AbortSignal.timeout(4500),
    redirect: "manual",
    cf: { resolveOverride: "origin-bypass.example.com" }
  });
  if (!FALLBACK_STATUSES.has(origin.status)) return origin;
  return serveSnapshot(request, origin.status);
} catch {
  return serveSnapshot(request);
}

if (!new Set(["GET", "HEAD"]).has(request.method)) {
  return new Response("Temporarily unavailable", {
    status: 503,
    headers: {
      "Retry-After": "300",
      "Cache-Control": "no-store",
      "Content-Type": "text/plain; charset=utf-8"
    }
  });
}

# Build from rendered production and validate the package
python scripts/build_snapshot.py
npm run types
npm run check
npx wrangler deploy --env staging --dry-run

# Deploy and test the private preview (use your own secret securely)
npx wrangler deploy --env staging
python scripts/smoke_staging.py --base "https://<private-preview>" --password "<secret>"

# Inspect, activate, or remove only the owned routes
python scripts/manage_routes.py status
python scripts/manage_routes.py activate --confirm ACTIVATE-KBT-FALLBACK
python scripts/manage_routes.py deactivate --confirm REMOVE-KBT-FALLBACK

Testplan: Fehler, Pass-through und Recovery beweisen

Matrix: Startseite, Kerntool, CSS/JS, Artikel, Arabisch RTL, lange Lokalisierung, robots, Missing Path, HEAD, Formular-POST, www-Redirect sowie Light/Dark mobil.

Im Snapshot-Modus Header, Canonical, H1, JSON-LD, Assets und Hinweis prüfen; im Origin-Preview direkten Zugriff ohne Schleife; live bei gesundem Host fehlenden Fallback-Header und unveränderte Antwort/Redirects/Tracking.

Production-Origin nie absichtlich stören. Privates Preview oder separaten Fehler-Origin nutzen und Generierungszeit plus Manifest-Hash protokollieren.

Rollback, Ereignisüberwachung und Recovery

Sofort-Rollback ist das Entfernen nur der eigenen Worker-Routen, nicht DNS-Umbau oder Worker-Löschung. Apex/www direkt prüfen und Cache nur bei altem Fallback-HTML leeren.

Während der Wartung Header, Origin-Status, Logs, Schlüsselseiten und 503-Aktionen beobachten. Der erste gesunde Origin-Response übernimmt automatisch. Danach Stabilität prüfen, temporäre Rechte entziehen, Messwerte sichern und Snapshot erneuern.

Zwei Fallen: Same-Zone-Rekursion und Free-Limit

Ein Worker auf keyboardtester.click/* darf beim Origin-Fetch nicht naiv denselben öffentlichen Host aufrufen. Mit Cloudflares dokumentiertem resolveOverride und einem bestehenden DNS-only-Host derselben Zone geht die Auflösung direkt zum Origin, während URL und Host-Header kanonisch bleiben. Origin-Adresse und Bypass-Infrastruktur gehören nicht in eine öffentliche Anleitung.

Der Free-Plan erlaubt derzeit 100.000 Worker-Requests pro Tag, 20.000 statische Dateien je Version und 25 MiB je Datei. Unsere 2.749 Dateien passen. Beide Routen sind request-limit fail-open: Bei ausgeschöpftem Kontingent umgeht Cloudflare den Worker und geht direkt zu HostArmada, statt Error 1027 auszugeben. Für Verfügbarkeit ist das richtig; für eine Sicherheitskontrolle wäre es falsch.

SEO, Werbung und Analytics im Fallback

Vorhandene Snapshot-Seiten antworten unter den Original-URLs mit 200, Canonical, Schema und internen Links. Nicht verfügbare Schreibaktionen antworten 503. Es gibt keine separate öffentliche Backup-Domain und keine neuen URLs zum Einreichen.

Staging ist passwortgeschützt, robots-blockiert, noindex und ohne Tracking. Nur Produktions-Snapshot-HTML erhält verzögertes GA4 und AdSense; Clarity nur auf der Startseite. Gesunde Origin-Antworten bleiben unberührt. Messung und mögliche Anzeigen bleiben erhalten, aber Anzeigenfüllung und Einnahmen sind nie garantiert.

We did not submit fallback URLs to search engines because there are no new public URLs. The continuity layer sits behind the same addresses Google already knows.

Die Production-Injektion folgt der Live-Performance: GA4 nach Interaktion oder 2 Sekunden nach load, AdSense nach Interaktion oder 15 Sekunden, Clarity nur auf der Startseite nach Interaktion oder 12 Sekunden. Streaming-HTMLRewriter ändert nur Fallback-GET-HTML, nie HEAD, CSS, JS oder Bilder.

Grenzen und geeignete Einsatzfälle

Formulare, serverseitige KI, E-Mail, Datenbankschreibvorgänge, Sessions und gespeicherte Einsendungen bleiben während des Origin-Ausfalls offline. Ein Browser-Tool funktioniert nur, wenn alle benötigten Dateien im Snapshot liegen.

Der Snapshot altert. Nach größeren Content-, Template-, Skript- oder Assetänderungen muss er erneuert und inklusive Wiederherstellung getestet werden. Schreib- und transaktionslastige Produkte brauchen replizierte Anwendung und Datenbank statt dieses Musters.

Für eine contentlastige Shared-Hosting-Site mit vielen clientseitigen Tools war es passend: kein Daten-Split, kein manueller Cutover, keine zweite öffentliche Domain und ein klarer Degradationsmodus. Es verkleinert die sichtbare Ausfallzeit, beseitigt aber nicht jede Abhängigkeit.

Primärquellen und eigene Nachweise

Die Messwerte stammen aus unseren Manifesten sowie Deployment- und Live-Routenprüfungen vom 17.–18. Juli 2026. Produktverhalten und Grenzen sind in den verlinkten Primärquellen dokumentiert.

• Cloudflare Workers: Static Assets
• Cloudflare Workers: Platform Limits
• Cloudflare Workers Request API
• Cloudflare Workers Routes API
• RFC 9110: HTTP Semantics
• HostArmada support correspondence, July 16–17, 2026

Häufige Fragen

• Wird Shared Hosting damit wirklich ausfallfrei?

  Nein. Eine vorbereitete Lesekopie bleibt verfügbar; Formulare, Writes, E-Mail, serverseitige KI und Sessions benötigen weiter den Origin.

• Muss ich beim Ausfall DNS ändern?

  Nicht bei diesem Always-on-Muster. Der Worker prüft jeden Request und kehrt nach der Erholung automatisch zum Origin zurück.

• Sieht Google für jede URL eine Wartungsseite?

  Nein. Vorhandene Snapshot-Seiten bleiben 200 mit Canonical und Schema; nicht verfügbare Aktionen erhalten temporär 503.

• Warum nicht das ganze Konto kurz migrieren?

  Hin- und Rückmigration kann DNS-, Datenbank-, Datei- und E-Mail-Synchronisationsrisiken erzeugen. Wir vermieden einen zweiten beschreibbaren Stack.

• Warum resolveOverride?

  Damit der Worker auf dem öffentlichen Host nicht sich selbst aufruft. DNS wird über einen alternativen Same-Zone-Host aufgelöst, URL und Host bleiben kanonisch.

• Was passiert am Free-Tageslimit?

  Die Routen sind fail-open: Cloudflare umgeht den Worker und geht direkt zum Origin. Das entfernt im Origin-Ausfall den Fallback, verhindert aber einen zusätzlichen Quotenfehler.

• Wie oft muss der Snapshot neu gebaut werden?

  Nach wesentlichen Content-, Template-, Skript- oder Assetänderungen und vor geplanter Wartung; Ausfall und Wiederherstellung jedes Mal testen.

Die Lehre lautet nicht „alles hinter einen Worker“. Wähle die kleinste passende Kontinuitätsschicht, teste sie privat, benenne Grenzen ehrlich und automatisiere die Rückkehr.