Push fehlgeschlagen — was zu prüfen ist

Wenn ein Push fehlschlägt, zeigt der Activity-Stream ein rotes Fehlgeschlagen-Badge mit einer Fehlerkategorie. Diese Seite mappt Fehler-Kategorien auf Lösungen.

Den fehlgeschlagenen Push finden

Dashboard → Activity → nach Status: Fehlgeschlagen filtern. Klick einen fehlgeschlagenen Event an, um das volle Payload, die Fehlermeldung, den HTTP-Status-Code und die Timing-Aufschlüsselung zu sehen.

Die Event-Zeile sagt dir, welche Site, welche Tokens und welche Fehler-Kategorie schuld ist.

Fehler-Kategorien

auth_failed (HTTP 401)

Das WP-Plugin hat die HMAC-Signatur abgelehnt. Ursachen:

• Geklonte DB: Produktiv-DB wurde nach Staging kopiert (oder umgekehrt). Beide Sites haben jetzt dasselbe api_secret, aber Hubbee hat nur eine registriert. Die andere lehnt alle Pushs ab.
  • Fix: Verbinden auf der geklonten Site neu durchlaufen für frisches Secret.
• Zeit-Drift: WP-Server-Uhr weicht von Hubbee-Server-Uhr um >5 Minuten ab.
  • Fix: ntpdate laufen lassen oder einen Time-Sync-Service auf dem WP-Host aktivieren.
• Plugin reinstalliert mit WP-CLI, das Daten droppt: das api_secret-Option wurde gewipet.
  • Fix: Neu verbinden.

timeout (keine Antwort in 30 Sekunden)

Der REST-Endpoint des Plugins hat nicht vor Hubbees Timeout geantwortet. Ursachen:

• WP-Server überlastet (hoher Traffic, langsame DB)
• Ein WP-Plugin (oft Caching, Security, Wartung) blockiert den Request
• wp-json-Permalinks kaputt

Test:

curl -X POST https://your-site.example/wp-json/bz/v1/health -m 35

Wenn das hängt, liegt’s am WP-Layer. Siehe Plugin offline für die breitere Diagnose.

network_error (keine TCP-Verbindung)

Hubbee konnte die WP-Site gar nicht erreichen. Ursachen:

• Site offline (Homepage prüfen)
• DNS gerade geändert und Propagation nicht abgeschlossen
• Cloudflare oder ähnliche WAF blockiert Hubbees IP

Hubbees ausgehende IPs sind statisch. Falls eine WAF uns blockt, whitelisten:

46.225.120.136

validation_error (HTTP 400)

Das Plugin hat das Push-Payload als malformed abgelehnt. Ursachen:

• Token-Feldtyp geändert (z.B. text → richtext), aber Wert enthält noch Plain Text ohne Sanitisierung
• Token-Key enthält ungültige Zeichen (nur lowercase, Ziffern, Underscore erlaubt)
• Wert überschreitet 64 KB (Hubbees Per-Token-Limit)

Fix: Token im Dashboard editieren und neu speichern. Validierung läuft beim Speichern; nur gültige Werte können gepusht werden.

processed_with_errors (HTTP 200, aber errors: [...])

Push war technisch erfolgreich, aber spezifische Tokens sind WP-seitig fehlgeschlagen. Das Error-Array zeigt Per-Token-Detail:

• "key": "hero_title", "error": "field_type_mismatch" → Token-Feldtyp passt nicht zum erwarteten Elementor-/Theme-Widget
• "key": "X", "error": "locked_by_other_user" → ein anderes Teammitglied hat den Token zum Bearbeiten gelockt
• "key": "X", "error": "cache_invalidation_failed" → Push war erfolgreich, aber das Cache-Plugin konnte nicht flushen. Siehe Cache-Konflikte.

Retry-Verhalten

Fehlgeschlagene Pushs werden NICHT automatisch retried. Jeder Push ist eine einmalige Operation, die du startest (manuell oder geplant).

Wenn du das Grundproblem behoben hast und retrien willst:

• Aus Activity: fehlgeschlagenen Event öffnen → Retry. Push feuert erneut mit demselben Payload.
• Aus Tokens: Token editieren → Speichern & Pushen. Der aktuelle Wert aller Tokens in dieser Sektion wird geschickt.

Wann eskalieren

Wenn Pushs wiederholt ohne klare Kategorie fehlschlagen, oder der Activity-Stream einen generischen internal_server_error zeigt, Support-Thread öffnen mit:

• Fehlgeschlagene Event-ID (aus der URL beim Öffnen des Event-Details)
• Site-URL
• Ungefähre Zeit des Fehlers (ISO-Format mit Zeitzone)

Wir können von der Event-ID aus serverseitige Logs einsehen.