Plötzlicher Traffic-Anstieg: Was tun bei akuter Serverüberlastung (504-Fehler)?

Manchmal führt ein unerwartetes Ereignis – etwa eine Medienberichterstattung, eine virale Social-Media-Erwähnung oder eine große Marketingaktion – dazu, dass deine Website innerhalb kürzester Zeit ein Vielfaches des normalen Besucheraufkommens erhält. Das kann sowohl das Frontend als auch den Zugriff auf dein WordPress-Backend spürbar verlangsamen oder mit Fehlermeldungen wie 504 Gateway Timeout oder 508 Resource Limit Is Reached blockieren. Dieser Artikel zeigt dir, was du selbst tun kannst und wie dich unser Support in einer solchen Situation kurzfristig unterstützen kann.

Voraussetzungen

• Deine Website zeigt 504- oder 508-Fehler, insbesondere beim Zugriff auf /wp-admin.
• Du vermutest oder weißt, dass der Traffic gerade ungewöhnlich hoch ist (z. B. durch Presseberichte, Kampagnen oder Aktionen).
• Zugriff auf dein Plesk-Kundencenter bzw. Kontakt zum HostPress-Support.

Schritt-für-Schritt-Anleitung

1. Fehlerbild einordnen

Meldungen wie „upstream timed out“ oder „The timeout specified has expired“ in den Server-Protokollen deuten auf einen 504 Gateway Timeout hin: Der Server wartet zu lange auf eine Antwort und bricht die Anfrage ab, meist weil die zugewiesenen Ressourcen durch hohen Traffic ausgeschöpft sind. Die Protokolle findest du in deinem Plesk Panel.

• Interne Ursache: PHP-FPM-Überlastung durch Cron- und Plugin-Aktivität

Nicht jede plötzliche Nichterreichbarkeit deiner Website geht auf einen externen Besucheransturm zurück. Genauso häufig entsteht eine Überlastung durch interne Hintergrundprozesse deiner eigenen WordPress-Installation – vor allem dann, wenn mehrere ressourcenintensive Funktionen gleichzeitig aktiv sind.

Typische Auslöser für interne Überlastung

• WP-Cron: Bei WordPress wird der Cron-Mechanismus standardmäßig bei jedem Seitenaufruf über wp-cron.php mitausgeführt. Bei vielen gleichzeitigen Aufrufen kann das die PHP-Prozesse zusätzlich belasten.
• admin-ajax.php: Plugins, die häufig asynchrone Hintergrundanfragen stellen (z. B. Live-Suchen, Statistiken, Formulare), erzeugen viele parallele Aufrufe dieser Datei.
• WooCommerce-REST-Aufrufe: Externe Anbindungen (z. B. Warenwirtschaft, Marktplatz-Sync) können in kurzer Zeit viele API-Anfragen auslösen.
• Kalender-/Event-Plugins: Plugins mit wiederkehrenden Hintergrundaufgaben (z. B. Terminaktualisierungen) laufen oft automatisiert und unbemerkt im Hintergrund.
• Gleichzeitige Plugin-Updates: Automatische Updates mehrerer Plugins zur gleichen Zeit beanspruchen zusätzlich PHP-Ressourcen.

Da HostPress mit PHP-FPM arbeitet, steht für die Verarbeitung von Anfragen nur eine begrenzte Anzahl paralleler PHP-Prozesse (max_children) zur Verfügung. Sind alle Prozesse durch die oben genannten Hintergrundaufgaben belegt, können reguläre Seitenaufrufe zeitweise nicht mehr verarbeitet werden – die Website wirkt dann komplett offline (z. B. mit der Fehlermeldung ERR_TIMED_OUT im Browser) oder liefert 503-/504-Fehler.

Was du selbst tun kannst

• Prüfe, ob du Plugins nutzt, die regelmäßig externe Daten synchronisieren (z. B. WooCommerce-Anbindungen, Event-/Kalender-Plugins), und ob sich deren Ausführungsintervall verringern lässt.
• Erwäge, den echten WP-Cron zu deaktivieren und stattdessen einen serverseitigen Cron-Job mit einem sinnvollen, festen Intervall einzurichten – dadurch wird Cron nicht mehr bei jedem einzelnen Seitenaufruf mitausgeführt.
• Plane größere manuelle Plugin- oder Theme-Updates nach Möglichkeit außerhalb der Stoßzeiten deiner Website ein.
• Wenn eine ähnliche Nichterreichbarkeit wiederholt auftritt, teile dem Support die betroffene Domain sowie den ungefähren Zeitpunkt mit – so kann anhand der Server-Logs die genaue Kombination aus Hintergrundprozessen identifiziert werden.

Wichtig zu wissen

Eine höhere Serverleistung (mehr CPU/RAM) allein löst dieses Problem nicht zuverlässig: Wenn eine ineffiziente Schleife oder eine sehr hohe Anzahl gleichzeitiger Hintergrundaufrufe die vorhandenen Ressourcen ausschöpft, wächst der Bedarf oft mit der verfügbaren Leistung mit. Wichtiger als eine reine Kapazitätserhöhung ist es, die auslösenden Hintergrundprozesse zu identifizieren und zu entschärfen.

• Interne Ursache: Endlosschleifen durch Plugins oder fehlerhafte Page-Builder-Daten

Manchmal blockiert nicht die Menge der Anfragen deine PHP-Prozesse, sondern einzelne Anfragen, die nie fertig werden. Schon wenige solcher hängenden Prozesse reichen aus, um alle verfügbaren PHP-FPM-Worker zu belegen. Deine Website liefert dann 504-Fehler, obwohl kaum Besucher da sind. Mehr CPU oder RAM hilft in diesem Fall nicht, weil die Schleife jede zusätzliche Ressource ebenfalls verbraucht.

Typische Muster

• Hängende Übertragungen von Migrations- oder Sync-Plugins: Ein Plugin überträgt Dateien oder Datenbanken per REST-API (zum Beispiel bei einem Push/Pull zwischen Staging und Live). Bricht die Übertragung ab, startet das Plugin sie automatisch neu, oft im Minutentakt und über Stunden hinweg. Jeder Versuch bindet einen PHP-Prozess bis zum Timeout.
• Sich selbst referenzierende Page-Builder-Elemente: Bei Page-Buildern wie Elementor Pro kann ein globales Element (Global Widget, Template oder Section) durch einen Bearbeitungsfehler auf sich selbst verweisen. Beim Rendern ruft sich das Element dann immer wieder selbst auf. Einzelne PHP-Prozesse laufen minutenlang unter Volllast, und betroffen sind alle Seiten, auf denen dieses Element eingebunden ist.
• Plugins, die sich gegenseitig auslösen: Zwei Plugins reagieren auf dieselben WordPress-Hooks und lösen sich wechselseitig neu aus, zum Beispiel beim Speichern von Beiträgen oder Bestellungen.

Woran du das erkennst

• Die 504-Fehler treten auch bei normalem oder niedrigem Besucheraufkommen auf.
• Im Fehlerprotokoll in Plesk findest du Meldungen wie AH01075: Error dispatching request, upstream timed out oder Hinweise auf erreichte LVE-Limits (Fehler 508).
• Im Zugriffsprotokoll tauchen in kurzen, regelmäßigen Abständen immer wieder dieselben Anfragen auf, zum Beispiel an einen REST-API-Endpunkt eines bestimmten Plugins.
• Das Problem begann kurz nach einer Änderung: einer Migration, dem Bearbeiten globaler Page-Builder-Elemente oder einem Plugin-Update.
• Einen Crawler zu sperren oder einzelne Plugins zu deaktivieren, bringt kaum Besserung.

Was du selbst tun kannst

1. Laufende Übertragungen beenden: Öffne in deinem Migrations- oder Sync-Plugin die Übersicht der aktiven Jobs und brich hängende Übertragungen ab. Lass Migrationen auf einer Live-Website nicht unbeaufsichtigt laufen und deaktiviere das Plugin nach Abschluss der Migration.
2. Zuletzt bearbeitete globale Elemente prüfen: Wenn du kurz vor dem Ausfall globale Widgets, Templates oder Header/Footer im Page-Builder bearbeitet hast, stell die letzte funktionierende Version über die Revisionen des Elements wieder her. Füge ein globales Element nie in sich selbst ein, auch nicht über verschachtelte Templates.
3. Mit einer Staging-Kopie eingrenzen: Reproduziere das Problem auf einer Staging-Umgebung und deaktiviere dort Plugins schrittweise, statt auf der Live-Seite zu experimentieren.
4. Zeitpunkt und Änderungen notieren: Halte fest, seit wann die Fehler auftreten und welche Änderungen du davor vorgenommen hast. Das verkürzt die Analyse erheblich.
5. Support früh einbinden: Wenn du die Ursache nicht schnell findest, melde dich beim HostPress-Support. Wir können in den Server-Logs und an den laufenden PHP-Prozessen sehen, welche Anfrage hängt. Nenne uns die betroffene Domain, den Zeitraum und deine letzten Änderungen.

Wichtig: Ein Rollback einzelner Plugins, mehr Ressourcen oder strengere LVE-Limits behandeln nur die Symptome. Dauerhaft hilft nur, die Schleife selbst zu beseitigen, also die hängende Übertragung zu beenden oder das fehlerhafte Element zu reparieren.

• Externe Ursache: 503/504-Fehler durch Bot- oder Crawler-Traffic

Neben echten Besucherspitzen und internen Hintergrundprozessen kann auch automatisierter Bot- oder Crawler-Traffic zu 503- bzw. 504-Fehlern führen. Zwei Muster kommen dabei besonders häufig vor:

Gefälschte Browser-Kennung (User-Agent-Spoofing) über viele IPs

Manche automatisierten Systeme geben sich über einen gefälschten Browser-User-Agent (z. B. eine aktuelle Chrome-Version) als normaler Besucher aus und verteilen ihre Anfragen über sehr viele wechselnde IP-Adressen (z. B. aus einem Residential-Proxy-Netzwerk). Da unser Sicherheitssystem Imunify360/WebShield vor allem IP-basiert arbeitet (ein Schwellenwert pro einzelner IP-Adresse), greift der automatische Schutz bei dieser Art von verteiltem Traffic oft nicht, weil jede einzelne IP für sich betrachtet unauffällig bleibt. Bei stärkeren Lastspitzen kann das zu 503-/504-Fehlern und in Kombination mit vielen parallelen PHP-Prozessen auch zu sogenannten PMEM-Faults (Überschreitung des Arbeitsspeicher-Limits deines Hosting-Pakets) führen, wodurch im Extremfall auch Hintergrundprozesse wie dein WordPress-Cronjob abgebrochen werden.

Crawler-Traps durch kombinatorische URL-Strukturen

Wenn deine Website sehr viele URL-Kombinationen erzeugt (zum Beispiel durch Filter-, Tag- oder Archivseiten mit nahezu unbegrenzten Kombinationsmöglichkeiten, etwa bei Podcast- oder Produktarchiven), kann ein Crawler – auch ein grundsätzlich seriöser KI- oder Suchmaschinen-Crawler – in dieser Struktur „hängen bleiben“ und binnen kurzer Zeit zehntausende technisch einzigartige URLs abrufen. Da praktisch jede dieser URLs neu ist, greift der Seiten-Cache nicht (jede Anfrage ist ein Cache-Miss), was die Serverlast massiv erhöht und zu 503-Fehlern führen kann – unabhängig von einem klassischen DDoS-Angriff.

Was du tun kannst

• Prüfe deine Server-Logs (bzw. lass sie vom Support prüfen) auf ungewöhnlich viele Anfragen mit demselben User-Agent oder auf einen sehr hohen Anteil einzigartiger URLs in einem bestimmten Bereich deiner Website.
• Grenze kombinatorische URL-Bereiche technisch ein, zum Beispiel über `noindex`-Angaben oder gezielte `Disallow`-Regeln in der robots.txt (siehe Artikel „Funktion der robots.txt“).
• Wenn du einen konkreten, schädlichen Bot anhand von User-Agent und/oder Referrer identifizieren kannst, wende dich mit den gesammelten Log-Daten (Zeitstempel, Anzahl Requests, Statuscodes) an den HostPress-Support. Wir können verdächtigen Traffic bei Bedarf serverseitig gezielt blockieren (z. B. auf Nginx-Ebene, noch vor Apache/PHP).
• Wichtig: Auf klassischen Shared-Hosting-Tarifen lassen sich einzelne Bot-User-Agents nicht selbst serverseitig sperren – dafür ist der Support nötig.

Hinweis: Diese Fälle sind von absichtlich blockierten KI-Crawlern (siehe Artikel „Warum blockiert mein Hosting KI-Crawler wie ChatGPT, Claude oder Perplexity?“) zu unterscheiden – hier geht es umgekehrt um automatisierten Traffic, der deinen Server ungewollt überlastet.

• Vor dem Start einer Werbekampagne: Ist dein Caching aktiv?

Ein besonders häufiger und gut vermeidbarer Auslöser für eine plötzliche Serverüberlastung ist der Start einer bezahlten Werbekampagne (z. B. Google Ads, Social-Media-Ads) auf eine Landingpage, für die kein Seiten-Caching aktiv ist. Jeder Klick auf die Anzeige erzeugt dann eine komplett neue, ungecachte Anfrage, die vollständig von WordPress und der Datenbank neu berechnet werden muss. Bei hohem Klickvolumen kann das innerhalb weniger Minuten alle verfügbaren PHP-FPM-Prozesse blockieren und deine gesamte Website – nicht nur die Landingpage – offline nehmen.

Was diesen Fall zusätzlich verschärfen kann

• Ein Cookie-Consent-Banner-Plugin, das bei jedem Seitenaufruf zusätzliche, nicht cachebare Anfragen auslöst.
• Eine defekte oder falsch verlinkte Ziel-URL in der Kampagne: Läuft jeder einzelne Klick in einen Fehler oder ein Timeout, bleibt der zugehörige PHP-Prozess bis zum Ablauf der Wartezeit blockiert, statt die Anfrage schnell zu beenden – das verschärft die Überlastung zusätzlich erheblich.

Checkliste vor dem Kampagnenstart

1. Prüfe, ob für die Ziel-Landingpage das Seiten-Caching (z. B. HostPress RocketCache/WP Rocket) aktiv ist und tatsächlich greift.
2. Rufe die Ziel-URL der Kampagne selbst einmal auf und stelle sicher, dass sie fehlerfrei und ohne Timeout lädt.
3. Prüfe, ob ein Cookie-Consent-Banner oder ähnliche Plugins auf der Landingpage aktiv sind, die das Caching beeinträchtigen könnten.
4. Bei erwartetem sehr hohem Besucheraufkommen (z. B. großes Werbebudget, TV-Spot-Begleitung) kannst du zusätzlich vorab mit unserem Support sprechen, um kurzfristig mehr Server-Ressourcen einzuplanen (siehe Abschnitt „Temporäre Ressourcenerhöhung“ weiter unten).

Wenn die Website durch eine laufende Kampagne bereits überlastet ist

Folge in diesem Fall den Schritten weiter oben in diesem Artikel (Fehlerbild einordnen, Wartungsmodus, Support kontaktieren, temporäre Ressourcenerhöhung). Melde dich zusätzlich möglichst schnell auch bei der Stelle, die die Kampagne schaltet (Marketing-Team oder Agentur), damit die Kampagne pausiert oder die Ziel-URL angepasst werden kann, bis das Caching aktiviert ist.

• Akuter 504-Fehler: Hängende PHP-Prozesse selbst zurücksetzen

Wenn deine Website plötzlich nur noch 504 Gateway Timeout liefert und im Fehlerprotokoll Meldungen wie AH01075: Error dispatching request oder The timeout specified has expired stehen, sind meist alle PHP-Prozesse belegt. Oft hängen sie noch an Anfragen, die längst niemand mehr braucht. Auch wenn die Ursache, etwa ein Bot-Ansturm, schon vorbei ist, bleibt die Seite dann so lange blockiert, bis diese Prozesse beendet werden.

Wartungsmodus in Plesk kurz ein- und wieder ausschalten

1. Melde dich in Plesk an und öffne Websites & Domains.
2. Öffne bei der betroffenen Domain das WordPress Toolkit und aktiviere den Wartungsmodus.
3. Warte etwa 10 bis 20 Sekunden und deaktiviere den Wartungsmodus wieder.
4. Rufe deine Website in einem privaten Browserfenster auf und prüfe, ob sie wieder normal lädt.

Beim Umschalten werden die PHP-Prozesse deiner Website neu gestartet, hängende Anfragen werden dabei beendet. Das ist eine Soforthilfe, keine Ursachenbehebung. Tritt der Fehler erneut auf, melde dich beim Support (siehe Checkliste unten).

Sonderfall Online-Shop: Bots umgehen den Seiten-Cache

Bei WooCommerce-Shops beobachten wir häufig Botnetze, die sich mit gefälschten Browser-Kennungen tarnen und gezielt URLs mit dynamischen Parametern aufrufen, zum Beispiel:

• ?add-to-cart=… (In den Warenkorb legen)
• ?add_to_wishlist=… (Wunschliste)
• URLs mit _wpnonce oder Filter- und Sortierparametern

Solche Aufrufe werden bewusst nicht gecacht, weil sie den Warenkorb verändern. Jede Anfrage muss deshalb vollständig von PHP und der Datenbank berechnet werden. Kommen Tausende davon von Hunderten wechselnder IP-Adressen, ist der Shop in Minuten überlastet. Ein Update oder eine Änderung von dir ist dafür nicht nötig. Zusätzliche SEO-Crawler (z. B. DotBot, SemrushBot) verschärfen die Lage.

Was du tun kannst:

• Setz die PHP-Prozesse wie oben beschrieben zurück, um den Shop sofort wieder erreichbar zu machen.
• Lass vom Support auswerten, welche Bots und IP-Bereiche beteiligt waren. Wir können verdächtigen Traffic serverseitig sperren.
• Entscheide selbst, ob SEO-Crawler gesperrt werden sollen. Ohne deine ausdrückliche Zustimmung sperren wir sie wegen möglicher SEO-Auswirkungen nicht.

Diese Angaben helfen dem Support bei der Analyse

• alle betroffenen Domains, besonders wenn mehrere Websites gleichzeitig betroffen waren
• Beginn und Ende der Störung mit Datum, Uhrzeit und Zeitzone (z. B. „12:00–13:00 Uhr deutscher Zeit“)
• genaue Fehlermeldung bzw. Statuscode (504, 503, 508) und ob Frontend, Backend oder beides betroffen war
• was du kurz vorher geändert hast (Updates, Kampagnen, Newsletter, Migrationen), oder dass du nichts geändert hast
• ob das Zurücksetzen per Wartungsmodus geholfen hat

Je präziser der Zeitraum, desto schneller können wir in den Server-Logs erkennen, ob ein Bot-Angriff, eine Lastspitze auf dem Server oder ein Prozess deiner eigenen Website die Ursache war.

2. Wartungsmodus als kurzfristige Entlastung aktivieren

Wenn ein Teil deiner Besucher vorübergehend auf eine einfache Hinweisseite umgeleitet werden kann, reduziert das die Serverlast spürbar. Aktiviere dazu den Wartungsmodus deiner Website. Das ersetzt keine dauerhafte Lösung, verschafft dir aber Zeit, um weitere Schritte einzuleiten.

3. Support kontaktieren und Situation schildern

Melde dich bei akuten Traffic-Spitzen zeitnah beim HostPress-Support und schildere kurz die Situation (z. B. Ursache des Traffic-Anstiegs, betroffene Domain, ob das Backend erreichbar sein muss). Teile uns mit:

• die genau betroffene Domain (falls du mehrere Domains/Umgebungen hast, gib an, welche nicht betroffen ist),
• ob du weiterhin Zugriff auf das Backend benötigst,
• eine grobe Einschätzung, wie lange die Situation voraussichtlich anhält.

4. Temporäre Ressourcenerhöhung

Bei akuten Lastspitzen kann der Support die zugewiesenen Server-Ressourcen (CPU/RAM) deines Hosting-Pakets kurzfristig erhöhen, um mehr gleichzeitige Anfragen verarbeiten zu können. Diese Erhöhung ist eine temporäre Kulanzmaßnahme für den akuten Ausnahmefall und kein dauerhafter Tarif-Upgrade-Ersatz. Bitte beachte: Bei Shared-Hosting-Umgebungen sind einer Ressourcenerhöhung technische Grenzen gesetzt.

5. Temporären Backend-Zugriff per IP-Beschränkung sichern

Wenn du dringend ins Backend musst, aber der allgemeine Andrang das verhindert, kann eine temporäre IP-Beschränkung helfen, die nur deine eigene IP-Adresse zum Zugriff zulässt. Dafür kann folgender Code-Block an den Anfang der .htaccess-Datei eingefügt werden (Platzhalter durch deine tatsächliche IP-Adresse ersetzen):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.123.123.123$
RewriteRule ^ - [R=503,L]
</IfModule>

Dadurch erhalten alle Besucher außer der angegebenen IP-Adresse eine 503-Meldung, während du selbst weiterhin normal auf die Seite zugreifen kannst. Entferne diesen Block wieder, sobald die Situation sich normalisiert hat.

6. Nach der Spitze: Ressourcen wieder zurücksetzen lassen

Sobald der Traffic wieder auf ein normales Niveau zurückgegangen ist, informiere den Support, damit die temporär erhöhten Ressourcen wieder auf den regulären Tarif zurückgesetzt werden können. Wenn du merkst, dass dein reguläres Besucheraufkommen dauerhaft gestiegen ist, sprich mit uns über einen passenden Tarif-Wechsel.

Mehrere unabhängige Websites auf demselben Server gleichzeitig betroffen

Neben dem oben beschriebenen Fall, bei dem ein einzelnes Plugin auf deiner Website 504-Fehler auslöst, gibt es ein zweites, ähnlich aussehendes, aber anders zu behandelndes Szenario: Mehrere voneinander unabhängige Websites auf demselben (gemeinsam genutzten) Server sind zur gleichen Zeit mit 504-Timeouts konfrontiert, obwohl an diesen Websites selbst nichts geändert wurde.

Woran du das erkennst

• Die 504-Fehler treten zeitgleich auf mehreren, inhaltlich und technisch unabhängigen Websites auf (z. B. unterschiedliche Shop- oder Kundenprojekte auf demselben Hosting-Paket bzw. Server).
• Du hast selbst keine Plugin-Updates, Theme-Wechsel oder sonstigen Änderungen vorgenommen, kurz bevor das Problem auftrat.
• Die Website funktioniert zeitweise wieder normal und fällt dann erneut für kurze Zeit aus, oft über mehrere Stunden verteilt.

Mögliche Ursachen

• Serverweite Ressourcenerschöpfung: Wenn gleichzeitig sehr viele Prozesse laufen (z. B. weil mehrere Websites auf dem Server parallel stark frequentiert werden), können die verfügbaren PHP-Prozess-Slots des Servers vollständig ausgelastet sein. Das betrifft dann nicht nur eine einzelne Website, sondern alle Websites auf demselben Server.
• Ungewöhnlich hoher Bot- oder Spam-Traffic: Automatisierte Zugriffe (auch KI-gestützte Bots) können in kurzer Zeit sehr viele Anfragen erzeugen und dadurch Serverressourcen binden, die dann anderen Websites auf demselben Server fehlen.
• Mehrere Websites mit ressourcenintensiven Plugins gleichzeitig: Auch wenn keine einzelne Website offensichtlich fehlerhaft konfiguriert ist, kann die Summe mehrerer, für sich genommen unauffälliger Plugins (z. B. Newsletter-Cronjobs, Tracking-Plugins, Caching-Plugins, die sich gegenseitig blockieren) in Kombination zu einer serverweiten Überlastung führen.

Was du tun kannst

1. Bevor du eine einzelne Website oder ein einzelnes Plugin verdächtigst: Prüfe, ob noch andere Websites auf demselben Hosting-Paket bzw. Server betroffen sind. Wenn ja, ist eine serverweite Ursache wahrscheinlicher als ein Einzelfall.
2. Notiere dir den genauen Zeitraum (Datum und Uhrzeit) der Ausfälle so präzise wie möglich – das hilft beim Auswerten der Server-Logs erheblich.
3. Kontaktiere den HostPress-Support mit dem Hinweis, dass mehrere Websites auf dem Server gleichzeitig betroffen waren, und teile den genauen Zeitraum mit. Der Support kann dann prüfen, ob z. B. PHP-Prozess-Limits (max_children) angepasst oder auffällige Zugriffsmuster (z. B. über die Web Application Firewall) eingegrenzt werden müssen.
4. Prüfe unabhängig davon auch die eigene Website auf ressourcenintensive Plugins (siehe Hauptartikel oben) – auch wenn die Ursache serverweit ist, reduziert eine schlanke Plugin-Konfiguration die Auswirkungen auf deine eigene Seite.

Fazit & Support-Hinweis

Ein plötzlicher Traffic-Anstieg lässt sich mit einer Kombination aus Wartungsmodus, temporärer Ressourcenerhöhung und gegebenenfalls einer IP-Beschränkung für den Backend-Zugriff meist gut überbrücken. Melde dich in einer solchen Situation frühzeitig bei unserem Support – je schneller wir über die Lage Bescheid wissen, desto gezielter können wir kurzfristig unterstützen.