¿Cómo decides sobre qué alertar en un servicio de backend?

Alerta sobre síntomas que nota el usuario, definidos como objetivos de nivel de servicio: disponibilidad y latencia medidas en el borde, más señales de corrección como pagos fallidos o una cola que deja de vaciarse. Manda un aviso urgente solo cuando un objetivo corre riesgo de incumplirse, usando la tasa de consumo del presupuesto de error, para que una deriva lenta genere un ticket y un consumo rápido despierte a alguien. Deja las alertas por causa, como CPU alta, en los paneles y no como avisos urgentes.

Parto de lo que notaría un usuario: peticiones que fallan, peticiones lentas y las cosas propias del dominio que son peores que ambas, como pedidos sin confirmar o un retraso de consumidor que no para de subir. Eso se convierte en objetivos con una meta, por ejemplo un 99,9 por ciento de peticiones con éxito y un percentil 95 de latencia por debajo de trescientos milisegundos, medidos en el balanceador y no dentro de la app, para contar los fallos que mi código nunca ve. Después la gravedad de la alerta sale de la tasa de consumo: quemar el presupuesto de error mensual en una hora avisa de inmediato, mientras que un consumo lento durante días es un ticket. Las métricas de causa como CPU, memoria o disco se quedan en paneles y en alertas de capacidad, porque una CPU ocupada que nadie nota no es un incidente. Cada aviso urgente tiene que ser accionable, así que enlaza a un runbook, y todo lo que se dispara sin acción se revisa. En un equipo recortamos el volumen del busca en torno a dos tercios así, y la victoria real fue que las alertas que quedaron se empezaron a tomar en serio.