Ein Push ist fehlgeschlagen — was jetzt

3 Min LesezeitAktualisiert am 2026-05-28

Ein Push ist fehlgeschlagen — was jetzt

Ein “Push” ist alles was Hubbee zu WordPress-Site schickt: Token-Werte, Background-Assets, Custom-Components, Text-Effekte, Plugin-Install-Commands. Meiste Pushes succeed in unter 2 Sekunden. Wenn sie fehlschlagen, Dashboard zeigt typed Error und wir retry automatisch.

Failure finden

Site-Detail → Activity → Push events. Klick failed Row für Expand. Drei Felder zählen:

  • Error code (typed Enum wie wp_403, hmac_mismatch, plugin_timeout)
  • HTTP status (raw Response-Code von WordPress)
  • Retries (wie viele Attempts so far)

Häufige Error-Codes

wp_403 — WordPress returned forbidden. Meist Security-Plugin das Request blockt. Siehe Firewall- und Security-Plugin-Konflikte. Hubbee retried 3× mit Exponential Backoff (5s, 30s, 120s), dann surface Failure. Manual Retry vom Push-Event-Detail nach Firewall-Fix.

wp_401 — Authentication failed. Site’s api_secret matched nicht was Hubbee gespeichert. Causes:

  • WordPress aus Backup restored das Hubbee-Credentials überschrieben
  • Plugin reinstalled und State verloren
  • Site auf neues Hosting migriert

Fix: Site → Settings → Connection → Reconnect. Neuer Connection-Token, re-enroll. Bereits gepushter Content bleibt auf WordPress; nur Pipe zwischen Hubbee und Site wird rebuilt.

hmac_mismatch — Signatur-Verification failed at WordPress. Entweder Request-Timestamp mehr als 5 Min off (Server-Clock-Drift auf WordPress-Seite) oder Man-in-the-Middle-Proxy munged Request-Body. Check Host’s NTP-Sync (timedatectl status auf Linux); wenn Clock off um mehr als 60s, NTP-Config fixen. Wenn Clock fine, nach Reverse-Proxy oder CDN suchen das Request-Bodies in-flight modifiziert.

plugin_timeout — WordPress brauchte über 15 Sekunden für Response. Meist langsamer Host, busy DB, oder Plugin das Heavy-Work auf jedem Request macht (Yoast SEO Premium mit großer Site, Better Search Replace running, etc.). Push retried 3×. Wenn alle drei timeouten, Site ist zu slow für Pushes — Hosting upgraden, oder Pushes außerhalb Peak-Hours via Site → Schedule pushes.

network_error — Konnte Site gar nicht erreichen. DNS-Resolution failed, TLS-Handshake failed, oder Site komplett offline. Check Site in Browser, dann Retry push.

plugin_too_old — Site’s Plugin-Version unter Minimum. Plugin updaten: WP-Admin → Plugins → Hubbee → Update Now. Push retried automatisch alle 5 Min für erste Stunde, dann once-per-hour für 24h, dann stoppt. Update restartet Retry-Cycle.

asset_chunk_404 — Pushed Asset-Bundle nicht available. Background, Element oder Text-Effekt assigned aber compiled Chunk nicht auf Supabase-Storage. Selten — meist transient Deploy-Issue auf unserer Seite. Retry in 5 Min; wenn weiter fehlschlägt, Support emailen mit Asset-Slug.

token_too_large — Token-Value über 1 MB. WordPress und Hubbee refusen beide Token-Values über 1 MB. Content trimmen oder in mehrere Tokens splitten. HTML-Blocks hitten das selten; Raw-JSON-Dumps und Markdown mit Base64-Images häufig.

rate_limited — Site hat Per-Site-Push-Rate-Limit (1000/Stunde) gehit. Fast immer Result von Runaway-Loop irgendwo im Dashboard. Eine Stunde warten; Limit-Window sliden. Wenn du genuin >1000 Pushes/Stunde auf eine Site brauchst, Support emailen — Per-Site-Limit für legitime Bulk-Ops raisable.

Retry-Policy-Reference

Error-Class Initial-Retry Max-Retries Backoff
Network (Timeout, unreachable) 30s 3 Exponential
WordPress 5xx 60s 5 Exponential
WordPress 4xx (Auth) none 0 Nur Manual
Plugin too old 5 min 12 Linear
Internal (Asset 404, etc.) 5 min 3 Linear

Nach Max-Retries, Push moved zu Status failed und bleibt im Event-Log permanently für Audit. Failed Pushes resumen NICHT auto wenn Underlying-Issue gefixt — du musst Retry manuell klicken.

Was passiert mit WordPress-Seite bei Failed Push

Failed Pushes lassen WordPress unchanged. Entweder rejected bevor WordPress applied, oder Timeout bevor WordPress finished — entweder way bleibt previous Content. Dashboard-Activity-Log ist Source of Truth für was currently live ist.

Atomic Rollback

Für Pushes die applied haben aber du revert willst: Site-Detail → Activity → Push events → most recent successful Push → Drei-Punkt-Menü → Revert to this version. Plugin restored Snapshot von Token-Values at that Point.

Rollback klappt nur für Token-Pushes, nicht für Asset-Assignments oder Component-Installs (keine versioned History).

Bulk-Replay Failed Pushes

Wenn viele Pushes während Outage gefailt sind und du retry alle willst:

  1. Activity → Push events → Filter: status = failed, started > [Outage-Window]
  2. Select all → Bulk action → Retry

Hubbee dispatched mit 200ms-Stagger zwischen Calls damit WordPress-Site nicht geslamed wird.

Wann Support emailen

  • Gleiche Site, gleicher Push, fehlschlägt 3× nach Artikel-Follow
  • Push-Status sitzt bei running über 10 Min (different von Sync-Stuck — siehe Sync hängt)
  • Error-Code nicht in Liste oben und nicht obvious aus Response-Body im Event-Detail

War der Artikel hilfreich?

Du kommst nicht weiter?

Öffne einen Support-Thread und wir melden uns. Die meisten Antworten erfolgen werktags innerhalb weniger Stunden.

Support kontaktieren