Erros na sua loja online: como saber antes dos seus clientes

Numa segunda-feira de manhã, um cliente escreve: «Tentei pagar no sábado e não me deixava». Verifica e, de facto, desde sexta à noite o botão de pagamento não fazia nada. Uma atualização de um módulo, um script do gateway de pagamento que não carregava ou um certificado expirado. Dois dias de vendas perdidas, e soube-o porque um cliente se deu ao trabalho de avisar. A maioria não avisa: vai-se embora.

O que pode falhar sem que veja

• Erros 500 em páginas concretas: uma ficha, uma categoria, o carrinho. A página inicial funciona e julga que está tudo bem.
• Erros de PHP depois de atualizar a versão do PHP, um módulo ou o tema. Com o modo de depuração desligado, o cliente vê uma página em branco ou um erro genérico.
• Erros de JavaScript no checkout. O servidor responde bem, mas um script falha no navegador e o botão de pagar não reage. O servidor não dá por isso.
• Pagamentos sem encomenda: o cliente paga, o gateway cobra e a loja não cria a encomenda porque a notificação não chegou.
• Valores que não batem certo entre o cobrado e o total da encomenda.
• Tarefas agendadas paradas: o cron que sincroniza stock, envia e-mails ou regenera o sitemap deixou de correr.
• Memória esgotada ou tempos de espera em processos longos.

Onde olhar quando algo falha

1. Registos do servidor web (error log do Apache ou do Nginx) e do PHP.
2. Registos do PrestaShop: Parâmetros avançados → Registos e, no PrestaShop 1.7 e posteriores, a pasta var/logs.
3. O modo de depuração (_PS_MODE_DEV_ em config/defines.inc.php), que mostra o erro completo. Nunca o deixe ativo em produção para toda a gente: mostra caminhos e detalhes internos.
4. A consola do navegador (F12) no checkout, para os erros de JavaScript.
5. O painel do gateway de pagamento, para comparar cobranças com encomendas.

Monitorização externa: o mínimo

Um serviço que visite a sua loja a cada poucos minutos e o avise se não responder deteta a quebra total. É imprescindível, mas insuficiente: não vê um erro no carrinho, um pagamento que falha ou um script partido. Para isso é preciso vigiar a partir de dentro.

O que deve ter um bom sistema de avisos

• Detalhe suficiente para agir: mensagem de erro, ficheiro e linha, URL, se havia cliente ou funcionário, versão do PHP e do PrestaShop. «Erro 500» e mais nada obriga a investigar do zero.
• Agrupamento: o mesmo erro repetido mil vezes deve chegar como um aviso com um contador, não como mil mensagens.
• Limite por hora: se algo se partir por completo, um resumo em vez de uma avalanche.
• Prioridade para o dinheiro: os avisos de pagamentos não deveriam ser agrupados nem silenciados, porque cada um é uma encomenda concreta.
• Canais separados: os erros técnicos para o programador, os pagamentos para quem trata da administração.
• Dados sensíveis de fora: um aviso não deve incluir números de cartão, IBAN, palavras-passe nem tokens. Mascará-los antes de enviar é obrigatório e, com o RGPD em mente, recomendável também para e-mails e documentos de identificação.

Porquê no telemóvel

O e-mail de avisos acaba numa pasta que se revê quando se pode. Uma mensagem numa aplicação de mensagens vê-se no momento. O Telegram é muito usado para isto porque os seus bots se configuram em minutos, admitem grupos e não têm custo.

Uma rotina que funciona

1. Depois de cada atualização (do PrestaShop, do PHP, de um módulo ou do tema), faça uma encomenda de teste completa.
2. Todas as semanas, reveja os erros agrupados dos últimos sete dias, mesmo que ninguém se tenha queixado.
3. Todos os dias, compare as cobranças do gateway com as encomendas, ou deixe que uma conciliação automática o faça.
4. Todos os meses, verifique que as tarefas agendadas continuam a correr.

Checklist

1. Tem uma monitorização externa de disponibilidade.
2. Recebe os erros de PHP e os 500 com detalhe.
3. Vigia os erros de JavaScript no checkout.
4. É avisado de pagamentos sem encomenda e de valores que não batem certo.
5. Os avisos são agrupados e têm um limite.
6. Os dados sensíveis são mascarados.
7. O modo de depuração está desligado para o público.

Como resolvê-lo no PrestaShop

RKR Sentinel envia para o Telegram os erros de PHP, exceções, erros fatais, memória esgotada, tempos de espera e respostas 500 com mensagem, ficheiro e linha, excerto de código, rastreio, URL, cliente ou funcionário, carrinho e versões, e cada tipo de erro pode ir para um chat diferente. No navegador captura os erros de JavaScript do checkout, incluindo os ficheiros que não carregam. Vigia cinco problemas de pagamento (pagamento sem encomenda, encomenda sem estado, valor que não bate certo, encomenda parada em erro de pagamento e cobrança desconhecida, com conciliação diária com PayPal e Stripe usando credenciais só de leitura), e os avisos de pagamento não são agrupados nem silenciados. Os erros são agrupados por impressão digital com um contador de repetições, há um limite de mensagens por hora e tudo passa por um filtro que mascara cartões, IBAN, documentos de identificação, tokens, palavras-passe e e-mails. A partir do chat tem sete comandos para consultar o estado, os erros, os pagamentos, uma encomenda ou um carrinho.