Portão de performance mal calibrado é pior que não ter: o time aprende a ignorar o vermelho (Módulo 3 de CI/CD). Os cuidados:

Limite com folga sobre a realidade medida. Meça primeiro em condições normais e coloque o threshold acima do observado, não colado nele. Threshold no limite do que já acontece falha por ruído.
Ambiente estável e dedicado. Rodar carga numa máquina compartilhada, que às vezes está ocupada, produz números diferentes a cada execução. Se não der para isolar, o portão precisa ser mais frouxo, e isso deve estar documentado.
Percentil, não máximo. Um max<3000 quebra com um único pico aleatório. Use p95 ou p99 como portão principal, e o máximo apenas para casos realmente inaceitáveis.
Carga curta no PR, longa fora dele. Um smoke de carga de 1–2 minutos a cada PR; o teste de carga completo agendado à noite. Pipeline de PR que demora 40 minutos ninguém espera.
Só o fluxo que importa. Portão no checkout e no login; não em toda rota do sistema.
Dado variado e massa recriada. Senão a segunda execução mede cache e a base cresce indefinidamente entre rodadas.
Excluir o que não é seu. Dependência externa em sandbox pode ser o gargalo, e você reprovaria o próprio build por causa do terceiro.
Revisar periodicamente. O sistema muda; um limite definido há um ano pode estar frouxo demais ou apertado demais.
Combinar antes. O time precisa concordar que o vermelho barra a entrega. Portão que todo mundo ignora é só um teste caro.

A regra que resume tudo: um portão só vale se o time confia nele o bastante para parar quando ele fecha.

Prova do Módulo 4