Er is een categorie storing die het vervelendst is van allemaal: de storing waar niemand iets van merkt. Uw homepage laadt, uw productpagina’s zien er goed uit, uw uptimemelder is de hele dag stil gebleven. En toch is er sinds gisterochtend geen enkele bestelling binnengekomen, omdat de knop “afrekenen” een foutmelding geeft zodra er meer dan één product in de wagen zit.

De meeste webshops bewaken één ding: of de website antwoord geeft. Dat is nuttig, maar het is de smalste vorm van webshop monitoring die er bestaat. Uw omzet hangt aan een keten van een stuk of zes schakels, en de meeste daarvan kunnen stukgaan terwijl de homepage vrolijk blijft laden. In dit artikel leest u welke schakels dat zijn, hoe u ze bewaakt en hoe u voorkomt dat u zo veel meldingen krijgt dat u ze niet meer leest.

Wat uptimecontrole wel en niet ziet

Een gewone uptimemelder vraagt elke minuut of vijf minuten uw homepage op en kijkt of er een antwoord komt met statuscode 200. Meer niet. Hij ziet dus wel:

  • Een server die eruit ligt.
  • Een verlopen SSL-certificaat, mits hij daarop controleert.
  • Een wit scherm of een fatale PHP-fout op de homepage.
  • Een domeinnaam die niet meer resolvt.

En hij ziet niet:

  • Een afrekenpagina die vastloopt terwijl de rest werkt.
  • Een betaalmethode die is uitgevallen of waarvan de API-sleutel is verlopen.
  • Een webhook die niet meer binnenkomt, waardoor betaalde bestellingen op “in afwachting” blijven staan.
  • Bevestigingsmails die niet worden verzonden.
  • Een voorraadkoppeling die is gestopt, waardoor u uitverkochte artikelen blijft verkopen.
  • Een site die technisch werkt maar acht seconden nodig heeft per pagina.

Al die dingen kosten u direct omzet of direct klanttevredenheid, en geen van alle geeft een melding als u alleen de voordeur in de gaten houdt.

De vier lagen die u zou moeten bewaken

Laag 1: bereikbaarheid

De basis. Controleer niet alleen de homepage maar minstens ook één productpagina, de winkelwagen en de afrekenpagina. Stel een controle in vanaf een Europese locatie, met een interval van één minuut voor de checkout en vijf minuten voor de rest. Voeg een controle toe op de geldigheidsduur van uw SSL-certificaat en op de vervaldatum van uw domeinnaam; die twee veroorzaken een verrassend deel van de complete uitval.

Laag 2: functionele controle van de bestelflow

Dit is de laag die de meeste shops missen. U laat een script periodiek de stappen doorlopen die een klant ook doorloopt: product openen, in de winkelwagen leggen, naar de afrekenpagina, controleren of de betaalmethoden zichtbaar zijn en of het totaalbedrag klopt. Zo’n synthetische controle draait bijvoorbeeld elk kwartier. Zodra er in stap drie iets verandert, weet u het binnen een kwartier in plaats van ‘s avonds bij het bekijken van de omzet.

Kunt u geen scriptcontrole draaien, dan is er een eenvoudiger alternatief dat verrassend goed werkt: een melding op basis van stilte. Komt er tussen 09:00 en 22:00 twee uur lang geen enkele bestelling binnen terwijl dat op een normale dag nooit gebeurt, dan stuurt uw shop u een bericht. Dat is een grove maat, maar hij vangt precies het scenario waar de omzet stilvalt zonder dat er iets kapot lijkt.

Laag 3: de betaalketen

Controleer of de koppeling met uw betaalprovider nog leeft en of webhooks binnenkomen. Concrete signalen die de moeite waard zijn:

  1. Bestellingen die langer dan dertig minuten op “in afwachting van betaling” staan terwijl er wel een betaling is gestart. Dat wijst bijna altijd op een webhookprobleem.
  2. Een sterke daling van het aandeel iDEAL in de betaalmethoden. Vaak het eerste signaal dat er iets mis is. Zie ook de oorzaken als iDEAL niet werkt.
  3. Foutmeldingen in het logbestand van uw betaalplugin. Vrijwel elke plugin schrijft die weg; niemand kijkt erin tot het te laat is.
  4. Verlopende API-sleutels en certificaten bij uw provider. Zet de vervaldatum in uw agenda.

Laag 4: alles daaromheen

Bevestigingsmails, voorraadkoppelingen, verzendkoppelingen en uw back-ups. Voor mail: laat uw shop dagelijks een testmail naar een postbus sturen en meld het als die uitblijft. Voor koppelingen: controleer of de laatste synchronisatie recent is. Voor back-ups: controleer niet of de taak is gestart maar of het bestand bestaat, of het groter is dan een minimumomvang en of het buiten de server staat.

Meldingen die u ook echt leest

Monitoring die te veel meldt, is monitoring die u uitzet. Een paar praktische regels die dat voorkomen:

  • Meld pas na twee mislukte controles. Eén hikje van drie seconden is geen storing.
  • Scheid urgent van niet-urgent. Checkout eruit: telefoon of WhatsApp. Een trage pagina of een aflopend certificaat: e-mail, of het maandrapport.
  • Meld ook het herstel. Anders blijft u in onzekerheid.
  • Spreek af wie reageert. Een melding zonder eigenaar is een melding die op zaterdagavond ongelezen blijft. Leg vast wie er kijkt binnen en buiten kantooruren.
  • Evalueer per kwartaal. Meldingen die nooit ergens over gingen, zet u uit of stelt u ruimer af.

Voor de meeste mkb-webshops is dit precies het soort werk dat wel moet gebeuren maar dat niemand intern oppakt. Het is ook de reden dat het onderdeel is van onderhoud voor WooCommerce-webshops: niet omdat het spannend is, maar omdat het het verschil maakt tussen een uur stil liggen en een dag stil liggen.

Een praktijkvoorbeeld

Een webshop in dierbenodigdheden uit Apeldoorn had een keurige uptimemelder en was daar tevreden mee. Na een update van een verzendkoppeling ging er iets mis met de berekening van de verzendkosten voor pakketten boven de tien kilo: de afrekenpagina gaf voor die orders een fout. Alle andere bestellingen liepen gewoon door, dus de omzet daalde wel maar viel niet weg. De uptimemelder zag niets. Het duurde negen dagen voordat een klant er telefonisch over begon.

Na die ervaring is er een kwartaalscript ingericht dat drie verschillende winkelwagens doorloopt, waaronder één met een zwaar product. De volgende keer dat er iets vergelijkbaars misging, kwam de melding binnen twintig minuten binnen.

Tot slot

Bewaak niet of uw website online is, maar of uw klant kan bestellen. Dat zijn twee verschillende vragen, en alleen de tweede gaat over uw omzet. Begin met de bestelflow, voeg de betaalketen toe, en maak dan pas de rest compleet.

Concrete volgende stap: zet vandaag een uptimecontrole op uw afrekenpagina in plaats van alleen op uw homepage, en stel een melding in als er tijdens openingstijden twee uur lang geen bestelling binnenkomt. Die twee ingrepen kosten samen een half uur en vangen het grootste deel van de storingen die u nu pas ‘s avonds ontdekt.