Kubernetes: un SLO para el correo de CI

Un pipeline de CI puede tener todos sus tests en verde y aun asi esconder un fallo importante: la aplicación genero el correo, pero nadie pudo comprobar que llego. En equipos que prueban registro, recuperación de cuenta o invitaciones, un temp mailbox controlado ayuda a separar la entrega real de una simple respuesta 200.

La lección operativa es tratar el correo como una dependencia con un objetivo de servicio. No hace falta convertir cada prueba en una plataforma enorme. Basta con definir que significa “entregado”, asignar un presupuesto de tiempo y guardar evidencia suficiente para investigar cuando el job falla.

La entrega del correo también necesita un SLO

Un SLO para un correo de prueba no promete que todos los mensajes del producto lleguen en un tiempo fijo. Describe una condición concreta del pipeline. Por ejemplo: “el mensaje de verificación debe aparecer en el buzón aislado dentro de 90 segundos, con el asunto esperado y un enlace para el entorno de staging”.

Esta definición evita una confusión muy comun: que el API acepte el mensaje no significa que el correo este disponible para el test. Hay al menos tres saltos: la aplicación publica el evento, el proveedor de correo lo procesa y el buzón lo expone para lectura.

Si el equipo ya trabaja con APIs, conviene separar los reintentos de negocio de los reintentos del test. Este enfoque sobre reintentos seguros en la verificación de email ayuda a no duplicar acciones solo porque una lectura fue lenta.

Define el contrato antes del job de Kubernetes

El job debe conocer el contrato de correo antes de arrancar. Un contrato pequeño puede incluir:

• Identidad: un buzón nuevo por ejecución, o un identificador de ejecución que no se repita.
• Mensaje esperado: remitente, asunto, tipo de evento y una marca como run_id.
• Ventana: cuanto tiempo esperar antes de declarar el caso como fallido.
• Seguridad: no poner tokens reales ni datos de usuarios en el mensaje de prueba.
• Evidencia: guardar el ID del mensaje, timestamps y el motivo de cada intento.

La identidad es especialmente importante en Kubernetes. Si dos pods comparten el mismo buzón, un test puede leer el correo de otro test y pasar por accidente. Un nombre como ci-${GITHUB_RUN_ID}-${JOB_ID} hace visible el límite de propiedad. Si el proveedor no permite crear buzones de forma automatica, se puede usar una colección controlada de buzones y reservar uno por lease.

Para escenarios manuales, un create temporary mail puede servir para inspeccionar un flujo puntual. En CI, sin embargo, lo importante no es tener una dirección rapida, sino que el buzón tenga una interfaz de lectura estable y que la ejecución pueda demostrar qué mensaje consumió.

Mide tres tiempos, no solo el resultado final

Un resultado binario —pasó o falló— es pobre para SRE. Registra al menos estos tiempos:

1. Tiempo de publicación: desde que el test pide la acción hasta que la aplicación confirma el evento.
2. Tiempo de transporte: desde ese evento hasta que el proveedor indica que aceptó el mensaje.
3. Tiempo de disponibilidad: desde la aceptación hasta que el mensaje puede leerse en el buzón.

Con esas marcas, el diagnóstico es mas corto. Si la publicación tarda, el problema puede estar en la aplicación o en la cola. Si la aceptación es rápida pero la disponibilidad se demora, hay que mirar el proveedor, el polling o los límites del buzón. Si el mensaje aparece pero no contiene el run_id, el fallo es de aislamiento, no de latencia.

Un pequeño registro JSON por ejecución es suficiente:

{
  "run_id": "ci-4821",
  "mail_event_id": "evt-91ab",
  "published_at": "2026-10-28T08:10:02Z",
  "accepted_at": "2026-10-28T08:10:04Z",
  "visible_at": "2026-10-28T08:10:19Z",
  "attempts": 4,
  "subject_match": true
}

No guardes el cuerpo completo si no hace falta. Un hash del mensaje, el asunto y los metadatos suelen bastar para investigar sin ampliar la superficie de datos sensibles.

Reintentos y fallos que sí ayudan a investigar

El polling debe tener una pausa y un limite. Reintentar cada milisegundo solo añade ruido y puede activar rate limits. Un backoff corto con un máximo, por ejemplo 2, 4, 8 y 16 segundos, suele ser mas amable con el proveedor. El job debe distinguir entre “todavía no visible”, “mensaje incorrecto” y “buzón no disponible”. Son fallos diferentes y piden acciones diferentes.

También conviene emitir una métrica por causa, no solamente un contador de jobs fallidos. email_visibility_timeout, wrong_run_id y mailbox_auth_error cuentan historias distintas. En una guardia, esa diferencia ahorra bastante tiempo.

El test no deberia reintentar una operación que crea un usuario si la primera petición pudo completarse. Primero consulta el estado con el identificador de ejecución; despues decide si hace falta repetir. Un correo repetido puede ocultar un problema de idempotencia.

Para no convertir staging en una papelera, aplica una retención breve y elimina los buzones o mensajes al terminar. Las pruebas de onboarding merecen la misma disciplina; puedes ver otro enfoque en probar correos de onboarding sin ensuciar métricas.

Preguntas frecuentes

¿Es obligatorio usar un proveedor de correo real?

No siempre. Un servidor SMTP local sirve para validar que la aplicación construye el mensaje. Para validar entrega, reglas del proveedor y lectura desde un buzón, necesitas una frontera mas parecida a producción. La elección depende de qué parte del contrato quieres cubrir.

¿Qué hago si el mensaje tarda más que el SLO?

Marca el job como fallido con el registro de tiempos y conserva la evidencia mínima. No aumentes la ventana cada vez que falla: primero comprueba si el retraso es de transporte, polling o aislamiento. Un SLO que cambia para ocultar ruido deja de ser util.

¿Puedo reutilizar el mismo buzón?

Solo si cada mensaje tiene un identificador único, el consumidor filtra por él y existe limpieza confiable. Un buzón dedicado por ejecución es mas simple de razonar, aunque puede costar más en trabajos muy frecuentes.

Checklist para el pipeline

• [ ] El mensaje contiene un run_id no reutilizado.
• [ ] El job tiene un presupuesto de entrega y un máximo de polling.
• [ ] Se registran publicación, aceptación y disponibilidad.
• [ ] Los reintentos no repiten operaciones no idempotentes.
• [ ] Los errores separan latencia, identidad y autenticación.
• [ ] No se envían datos reales al correo de prueba.
• [ ] Hay limpieza y retención definida para mensajes y buzones.
• [ ] El dashboard muestra tendencias, no solo el ultimo fallo.

En documentación informal alguien puede escribir “tempail” o “tem email”, pero el pipeline debe usar un vocabulario y un contrato exactos. Para SRE, la diferencia entre un correo aceptado y uno verificablemente disponible no es un detalle: es la frontera que convierte una prueba intermitente en una señal operable.