Wenn 200 parallele Requests ein System lahmlegen, liegt das Problem tiefer als in der Konfiguration. Es liegt in der Architektur.
In der Branche sprechen wir viel über gestohlene Credentials, kompromittierte API-Keys und falsch konfigurierte Zugriffsrechte. Das sind echte Risiken, die echte Aufmerksamkeit verdienen. Über Resilience spricht kaum jemand – und das ist das eigentliche Problem.
Verfügbarkeit ist das Fundament jeder ernsthaften Automatisierungsplattform. Wer Prozesse automatisiert, macht sie gleichzeitig abhängig von der Zuverlässigkeit der zugrundeliegenden Infrastruktur. Ein Ausfall trifft deshalb nie nur eine einzelne Aufgabe, sondern jeden Prozess, der auf ihr aufbaut.
Ein Strukturproblem, das sich wiederholt
Im Rahmen eines Security-Audits bin ich auf ein Muster gestoßen, das ich seitdem immer wieder erkenne: Webhook-Endpunkte sind häufig standardmäßig öffentlich erreichbar, unabhängig davon, ob sie aktiv genutzt werden. Ohne zusätzliche Authentifizierung, ohne Schutzmechanismen auf Anwendungsebene.
In einem kontrollierten Test-Szenario reichten rund 200 parallele Requests auf einen öffentlich verfügbaren Endpunkt, um die Datenbankverbindung zu destabilisieren.
Das Ergebnis: HTTP 503, keine Workflows mehr, vollständiger Stillstand. Kein Botnet, kein ausgefeilter Angriff. Fehlendes Rate-Limiting und eine Architekturentscheidung, die Resilience als nachrangig behandelt hatte.
Die Schwachstelle wurde im Rahmen der Responsible Disclosure gemeldet. Aber die eigentlich wichtige Frage ist eine andere.
Warum wird DoS bei Automatisierungsplattformen so selten ernst genommen?
Die Antwort liegt vermutlich in der Art, wie Automatisierungsplattformen bewertet werden: nach Features, nach Integrationstiefe, nach Benutzerfreundlichkeit. Verfügbarkeit ist schwerer zu demonstrieren. Sie fällt erst auf, wenn sie fehlt.
Das wird dann zum Problem, wenn Automatisierungen aufgehört haben, Helferwerkzeuge zu sein, und stattdessen operative Kernprozesse steuern. Wenn eine Plattform Rechnungsläufe auslöst, CRM-Systeme synchronisiert oder Produktionsdaten weiterverarbeitet, ist jeder Ausfall ein geschäftskritisches Ereignis mit messbaren Konsequenzen: verzögerte Rechnungen, fehlende Datenpunkte, manuelle Nacharbeit, die den eingesparten Aufwand schnell übersteigt.
Genau das zeigen die Zahlen aus der Praxis. Ein einzelner automatisierter Prozess bricht im Schnitt sechsmal pro Jahr zusammen. Jeder Ausfall dauert im Schnitt 120 Stunden, bis der Prozess wieder läuft, und die Ursache ist meistens unspektakulär: ein externer API-Endpunkt, der sich verändert hat, ein Timeout, der nicht abgefangen wurde, eine Lastspitze, auf die das System nicht ausgelegt war.
Der Unterschied zwischen 99,9 % und 92 % Uptime
| Uptime | Ausfallzeit / Jahr | Konsequenz |
|---|---|---|
| 99,9 % | 8,7 Stunden | Rote Dashboards, Postmortems |
| 99,0 % | 3,65 Tage | Kritisch für zeitkritische Prozesse |
| 92,0 % | 29,2 Tage | Niemand merkt es, bis jemand anruft |
92 % Uptime klingt zunächst akzeptabel. In der Realität bedeutet es fast 30 Tage Ausfall pro Jahr, verteilt auf viele kleine, stille Unterbrechungen. Kein Alert, kein Fallback, keine automatische Benachrichtigung. Es fällt auf, wenn eine Rechnung nicht angekommen ist, oder wenn jemand manuell fragt, warum Daten nicht synchronisiert wurden.
Das ist das eigentliche Risiko: der stille, schleichende Datenverlust im Hintergrund, der sich über Monate summiert, bevor ihn jemand beziffern kann.
Was Resilience by Design konkret bedeutet
Resilience lässt sich architektonisch nicht nachrüsten. Sie ist eine Grundsatzentscheidung, die früh getroffen werden muss.
In der Praxis heißt das: Jeder Webhook-Endpunkt, der öffentlich erreichbar ist, braucht einen definierten Schwellenwert für eingehende Requests und einen sauberen Mechanismus, um diesen Schwellenwert zu handhaben. Requests sollten so früh wie möglich validiert werden, bevor sie die Anwendungslogik oder die Datenbankverbindung erreichen. Eine vorgelagerte Authentifizierungsschicht reduziert die Angriffsfläche erheblich.
Genauso wichtig ist das Fallback-Verhalten. Was passiert, wenn ein externer Dienst nicht antwortet? Wenn eine API einen Timeout zurückgibt? Ein resilientes System hat darauf eine definierte Antwort. Und es meldet Ausfälle aktiv, weil stille Ausfälle meistens deshalb still bleiben, weil niemand aktiv hinschaut.
Das bedeutet Aufwand. Dieser Aufwand ist aber einmalig, während die Kosten eines schlecht abgesicherten Systems kontinuierlich anfallen.
Die Frage, die jedes Team beantworten sollte
Würde euer System 200 parallele Requests überleben?
Habt ihr das getestet? Gibt es einen definierten Schwellenwert? Einen Fallback? Ein Alert, wenn dieser Schwellenwert erreicht wird?
Wenn die Antwort unsicher ist, lohnt es sich, früher hinzuschauen als später. Ein System, das operative Prozesse trägt, muss resilient sein, bevor es neue Features bekommt.