Errores en tu tienda online: cómo enterarte antes que tus clientes

Un lunes por la mañana un cliente escribe: «Intenté pagar el sábado y no me dejaba». Revisas y, efectivamente, desde el viernes por la noche el botón de pago no hacía nada. Una actualización de un módulo, un script de la pasarela que no cargaba o un certificado caducado. Dos días de ventas perdidas, y te has enterado porque un cliente se tomó la molestia de avisar. La mayoría no avisa: se va.

Qué puede fallar sin que lo veas

• Errores 500 en páginas concretas: una ficha, una categoría, el carrito. La portada funciona y crees que todo va bien.
• Errores de PHP tras actualizar la versión de PHP, un módulo o el tema. Con el modo depuración apagado, el cliente ve una página en blanco o un error genérico.
• Errores de JavaScript en el checkout. El servidor responde bien, pero un script falla en el navegador y el botón de pagar no reacciona. El servidor no se entera.
• Pagos sin pedido: el cliente paga, la pasarela cobra y la tienda no crea el pedido porque la notificación no llegó.
• Importes que no cuadran entre lo cobrado y el total del pedido.
• Tareas programadas paradas: el cron que sincroniza stock, envía correos o regenera el sitemap dejó de ejecutarse.
• Memoria agotada o tiempos de espera en procesos largos.

Dónde mirar cuando algo falla

1. Registros del servidor web (error log de Apache o Nginx) y de PHP.
2. Registros de PrestaShop: Parámetros avanzados → Registros, y en PrestaShop 1.7 y posteriores la carpeta var/logs.
3. El modo depuración (_PS_MODE_DEV_ en config/defines.inc.php), que muestra el error completo. Nunca lo dejes activo en producción para todo el mundo: enseña rutas y detalles internos.
4. La consola del navegador (F12) en el checkout, para los errores de JavaScript.
5. El panel de la pasarela, para comparar cobros con pedidos.

Monitorización externa: lo mínimo

Un servicio que visite tu tienda cada pocos minutos y te avise si no responde detecta la caída total. Es imprescindible, pero insuficiente: no ve un error en el carrito, un pago que falla o un script roto. Para eso hace falta vigilar desde dentro.

Qué debe tener un buen sistema de avisos

• Detalle suficiente para actuar: mensaje de error, fichero y línea, URL, si había cliente o empleado, versión de PHP y de PrestaShop. «Error 500» sin más obliga a investigar desde cero.
• Agrupación: el mismo error repetido mil veces debe llegar como un aviso con un contador, no como mil mensajes.
• Límite por hora: si algo se rompe del todo, un resumen en lugar de una avalancha.
• Prioridad para el dinero: los avisos de pagos no deberían agruparse ni silenciarse, porque cada uno es un pedido concreto.
• Canales separados: los errores técnicos al desarrollador, los pagos a quien lleva la administración.
• Datos sensibles fuera: un aviso no debe incluir números de tarjeta, IBAN, contraseñas ni tokens. Enmascararlos antes de enviar es obligado, y con el RGPD en la mano, recomendable también para correos y DNI.

Por qué en el móvil

El correo de avisos acaba en una carpeta que se revisa cuando se puede. Un mensaje en una aplicación de mensajería se ve en el momento. Telegram es muy usado para esto porque sus bots se configuran en minutos, admiten grupos y no tienen coste.

Una rutina que funciona

1. Tras cada actualización (de PrestaShop, PHP, un módulo o el tema), haz un pedido de prueba completo.
2. Cada semana, revisa los errores agrupados de los últimos siete días, aunque nadie se haya quejado.
3. Cada día, compara cobros de la pasarela con pedidos, o deja que lo haga una conciliación automática.
4. Cada mes, revisa que las tareas programadas siguen ejecutándose.

Checklist

1. Tienes una monitorización externa de disponibilidad.
2. Recibes los errores de PHP y los 500 con detalle.
3. Vigilas los errores de JavaScript en el checkout.
4. Te avisan de pagos sin pedido e importes que no cuadran.
5. Los avisos se agrupan y tienen un límite.
6. Los datos sensibles se enmascaran.
7. El modo depuración está apagado para el público.

Cómo resolverlo en PrestaShop

RKR Sentinel envía a Telegram los errores de PHP, excepciones, fatales, memoria agotada, tiempos de espera y respuestas 500 con mensaje, fichero y línea, extracto de código, traza, URL, cliente o empleado, carrito y versiones, y cada tipo de error puede ir a un chat distinto. En el navegador captura los errores de JavaScript del checkout, incluidos los ficheros que no cargan. Vigila cinco problemas de pago (pago sin pedido, pedido sin estado, importe que no cuadra, pedido atascado en error de pago y cobro desconocido, con conciliación diaria contra PayPal y Stripe con credenciales de solo lectura), y los avisos de pago no se agrupan ni se silencian. Los errores se agrupan por huella con un contador de repeticiones, hay límite de mensajes por hora y todo pasa por un sanitizador que enmascara tarjetas, IBAN, DNI, tokens, contraseñas y correos. Desde el chat tienes siete comandos para consultar el estado, los errores, los pagos, un pedido o un carrito.