Un monitor de uptime puede mostrar 200 OK mientras Realizar pedido está muerto, el callback falla o todos los pagados siguen Pending. La monitorización transaccional debe recorrer los handoffs importantes sin crear cobros ni datos descontrolados.
Combina un recorrido sintético con señales operativas. Ninguna métrica aislada prueba salud.
Monitoriza el recorrido público
Desde navegador anónimo añade un producto de prueba, abre carrito/checkout, introduce una dirección controlada y confirma métodos.
- producto entra al carrito
- sesión sobrevive
- envío/impuestos calculan
- Place order responde correctamente
- orden llega al estado esperado
- limpieza se completaUsa sandbox o método offline diseñado para monitorización. Oculta el producto de búsqueda y fulfilment normal.
El monitor debe validar contenido, no solo HTTP 200: ID de variación seleccionado, método de envío, total calculado y estado final. Añade tiempos máximos por paso para distinguir lentitud de caída. Guarda capturas o respuestas sanitizadas solo cuando falla.
Evita contaminar informes
Usa identidad, SKU y prefijo de transacción dedicados. Segmenta pruebas en operaciones y analytics mediante reglas documentadas.
No borres pedidos pagados: reembolsa y concilia. Nunca uses cliente o tarjeta real en automatización. Limita frecuencia para no agotar stock, enviar emails o activar fraude.
Configura el SKU con stock reservado para pruebas o una política que no afecte disponibilidad pública. Marca destinatarios para que los mensajes de monitorización no lleguen al equipo de preparación. Revisa periódicamente que estas exclusiones no oculten pedidos reales.
Alerta sobre errores
Recoge fatals PHP, tasas 4xx/5xx y errores JavaScript sin datos personales. Agrupa por release, navegador y archivo.
No registres cuerpos, cookies o tokens. Hora e ID de correlación bastan. Alerta sobre huellas nuevas o crecientes, no warnings históricos.
Define umbrales por ruta y ventana, con severidad distinta para un error JavaScript cosmético y un fallo de wc-ajax=checkout. Agrupa repeticiones en un solo incidente y adjunta la primera/última hora, versión y porcentaje afectado.
Vigila callbacks
Monitoriza latencia y respuestas no 2xx por pasarela. Un retorno del navegador no demuestra confirmación servidor-servidor.
Relaciona fallos con pedidos Pending antiguos. Un timeout es incierto: verifica proveedor y orden antes de reproducir. Controla SSL y cambios DNS.
Detecta contradicciones
Crea reglas para cobros capturados sin orden pagada, Failed/Cancelled con éxito externo, capturas dobles y reembolsos ausentes.
Usa IDs estables y una ventana acotada. No incluyas tarjeta o datos personales. Enruta contradicciones a una persona capaz de pausar el método y conciliar.
La alerta debe incluir enlaces seguros a pedido y evento del proveedor, no datos financieros en email o chat. Define escalado si no se reconoce en minutos durante horas de venta. Una contradicción de pago no puede esperar al informe mensual.
Sigue las colas
Alerta si la Pending más antigua supera lo normal, aumentan fallos o throughput queda por debajo de creación.
La cola cubre email, suscripciones, webhooks, stock y fulfilment. El total aislado es débil. Verifica cron con un heartbeat independiente: un monitor dentro de WP-Cron roto no puede avisar de su ausencia.
Detecta fugas de sesión/caché
Ejecuta dos sesiones anónimas aisladas con carritos distintos y confirma que nunca se cruzan. Revisa cabeceras en Cart, Checkout y My account.
Calienta caché: en frío puede pasar y fallar tras HIT. Trata datos cruzados como incidente de privacidad y excluye páginas transaccionales inmediatamente.
Mantén al menos un monitor fuera de la red del hosting para detectar DNS/firewall públicos.
Ejecuta desde más de una región solo cuando la tienda venda allí y evita una frecuencia que parezca ataque. Un fallo desde una ubicación y éxito desde otra puede indicar CDN, DNS, geobloqueo o disponibilidad regional de la pasarela.
Crea alertas conscientes de releases
Registra cambios de WooCommerce, pasarela, tema, PHP, Cloudflare y consentimiento. Ejecuta la transacción tras cada cambio de riesgo, no solo mensualmente.
Silencia ventanas de mantenimiento de forma temporal y exige una prueba posterior. Una supresión permanente crea una caída silenciosa.
Asocia cada cambio con la primera ejecución posterior y conserva versión/commit o referencia del update. Si falla, el equipo debe poder decidir rollback con evidencia sin buscar qué se modificó.
La monitorización recurrente debe producir un incidente accionable con reproducción y referencias, no un aluvión de avisos vagos.
Mide tiempo de detección, reconocimiento y recuperación. Revisa falsos positivos mensualmente y ajusta umbrales sin eliminar los controles transaccionales esenciales.