Ein Push ist fehlgeschlagen — was jetzt
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:
- Activity → Push events → Filter: status = failed, started > [Outage-Window]
- 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?
Verwandte Artikel
Du kommst nicht weiter?
Öffne einen Support-Thread und wir melden uns. Die meisten Antworten erfolgen werktags innerhalb weniger Stunden.
