Een 504 Gateway Timeout op een WordPress-site betekent dat er twee servers in de keten zitten en dat de voorste tevergeefs op de achterste heeft staan wachten. Na een vastgestelde tijd, vaak dertig of zestig seconden, geeft hij het op en toont hij deze melding.

Er is dus niets kapot. Er duurde alleen iets te lang. Dat maakt de 504 tot een van de lastigere meldingen, want er wordt niet bij verteld wát er te lang duurde. Hieronder de aanpak die in de praktijk het snelst tot de bron leidt.

Het verschil met 502 en 503

Deze drie worden vaak door elkaar gehaald, terwijl ze naar verschillende problemen wijzen.

  • 502 Bad Gateway: de achterste server gaf een onbruikbaar antwoord. Vaak crashte er iets. De uitleg daarvan staat bij een 502-melding op uw WordPress-site.
  • 503 Service Unavailable: de server is tijdelijk niet beschikbaar, bijvoorbeeld door onderhoud of overbelasting. Meestal komt hij vanzelf terug.
  • 504 Gateway Timeout: de achterste server nam de tijd niet en gaf helemaal geen antwoord. Dit wijst op iets dat blijft draaien.

Praktisch verschil: bij een 502 zoekt u naar iets dat stukging, bij een 504 naar iets dat te zwaar is.

Eerst het onderscheid: overal of ergens?

Dit bepaalt de hele zoekrichting, dus doe dit voordat u iets anders probeert.

Op de hele site, ook op de homepage? Dan zit het probleem op serverniveau. Ga naar de statuspagina van uw hostingpartij of bel ze; bij een echte serverstoring bent u niet de enige.

Alleen op één pagina of één handeling? Dan weet u vrijwel zeker waar het zit. De klassiekers: een productimport, een zoekopdracht met veel filters, het opslaan van een lange pagina in een paginabouwer, of een overzicht met duizenden regels in het beheerscherm.

Alleen in het beheerscherm? Vaak een plugin die op de achtergrond iets zwaars doet, of een lijst die alle records tegelijk probeert op te halen.

Alleen op bepaalde momenten? Noteer die tijdstippen. Elke nacht om drie uur wijst op een geplande taak, bijvoorbeeld een back-up of een synchronisatie die de server tijdelijk volledig bezet.

Wat een 504 Gateway Timeout in WordPress meestal veroorzaakt

Een geplande taak die te zwaar is. Back-upplugins die een site van tien gigabyte in één keer proberen in te pakken, of een import die alle producten tegelijk bijwerkt. Oplossing: in stukken laten werken, of buiten kantooruren draaien.

Een trage databasezoekopdracht. Bij een grote site kan één slecht opgebouwde zoekopdracht een minuut duren. Dat komt vaak door een plugin die filtert op een veld waar geen index op staat. U herkent dit doordat de melding alleen komt bij overzichten met veel regels of bij filteren.

Een externe dienst die niet antwoordt. Dit is de meest onderschatte oorzaak. Uw site vraagt bij het laden van elke pagina iets op bij een andere partij: een koersfeed, een voorraadsysteem, een sociale tijdlijn. Ligt die partij eruit, dan blijft uw site wachten tot de tijd om is. Uw site is dan traag door andermans storing.

Te weinig ruimte op de server. Op gedeelde hosting krijgt u een beperkt aantal werkende processen. Zijn die allemaal bezet met langlopende verzoeken, dan komt er niets meer doorheen. Dit gaat vaak samen met een geheugenprobleem; zie het verhogen van de geheugenlimiet in WordPress.

Wat u zelf kunt proberen

  1. Zet de zwaarste plugins tijdelijk uit, met name back-up-, import-, statistiek- en beveiligingsplugins. Doe dat bij voorkeur in een testomgeving. Verdwijnt de 504, zet ze dan één voor één terug.
  2. Zet uw back-upschema op een rustig tijdstip en laat de back-up in delen werken als de plugin dat kan.
  3. Kijk of er een externe koppeling actief is die bij elke paginaweergave wordt aangeroepen. Zo ja, laat die de gegevens tussentijds bewaren in plaats van steeds live op te halen.
  4. Zet caching aan. Dat lost de oorzaak niet op, maar het zorgt ervoor dat de meeste bezoekers een opgeslagen versie krijgen en niets merken.
  5. Vraag uw hostingpartij naar de maximale uitvoeringstijd en of die verhoogd kan worden. Dat is een pleister, geen genezing, maar bij een import die nu eenmaal twee minuten duurt is het de juiste pleister.

Wat u níet doet: de tijdslimiet eindeloos ophogen en het daarbij laten. Een pagina die negentig seconden nodig heeft, is voor uw bezoekers alsnog onbruikbaar, en u verplaatst het probleem alleen naar een later moment.

De rol van de hostingpartij

Bij een 504 hebben zij informatie die u niet heeft. In hun logboeken staat welk proces bleef hangen en hoelang. Vraag daar concreet naar, met vermelding van het tijdstip en de pagina.

Twee vragen die goede antwoorden opleveren: “welke maximale uitvoeringstijd staat er op mijn account” en “ziet u in het logboek welk verzoek er op dat moment bleef draaien”. Krijgt u daar geen bruikbaar antwoord op, dan zegt dat iets over de partij.

Komt de melding structureel terug op een gedeeld pakket terwijl uw site niet uitzonderlijk zwaar is, dan zit u waarschijnlijk op een overvolle server. Dat is een reden om te verhuizen, niet om nog een plugin te installeren.

Wanneer u er iemand bij haalt

Een incidentele 504 tijdens een import is vervelend maar niet ernstig. Verschijnt hij meerdere keren per dag op gewone pagina’s, dan verliest u bezoekers en op termijn ook posities in Google, want zoekmachines noteren de site dan als onbetrouwbaar.

Het uitzoeken vraagt toegang tot serverlogboeken en meetgereedschap dat laat zien waar de tijd naartoe gaat. Dat is werk van een tot drie uur voor iemand die het vaker doet, en het begint altijd met meten in plaats van gokken. Bij het opsporen van storingen die telkens terugkomen is dat ook de volgorde: eerst vaststellen welk onderdeel de tijd opeet, dan pas ingrijpen.

Uw eerste stap kost een minuut: noteer wanneer de melding verschijnt en op welke pagina. Met die twee gegevens is de kans groot dat de oorzaak binnen een halfuur bekend is, ook als u zelf niet verder komt.