La respuesta corta

Para la mayoría de fundadores solos y equipos pequeños con poco tráfico, lo razonable es entre 7 y 30 días de logs calientes y consultables. Los logs de seguridad y auditoría merecen más tiempo (a menudo entre 90 días y un año, y en algunos casos más según la regulación). Lo que supere esa ventana, si es que lo necesitas, muévelo a almacenamiento frío o a un archivo aparte. Más allá de eso, todo es un equilibrio entre lo que pagas por guardar y la probabilidad real de que vuelvas a necesitar esos datos.

Esta guía te ayuda a elegir una ventana de retención adecuada para tu etapa, tu volumen de tráfico y tu presupuesto, sin copiar políticas pensadas para el equipo de seguridad de una empresa grande.

Por qué la retención es una decisión, no un valor por defecto

La mayoría de servicios de logging arrancan con una ventana predeterminada (suele ser 7, 14 o 30 días). Muchos fundadores indie aceptan ese número sin pensar si encaja con lo que realmente necesitan. Suele estar bien, hasta que algo se rompe justo en el día 31, o hasta que la factura se dispara porque el volumen de logs creció más rápido de lo previsto.

Decidir la retención es en realidad decidir cuatro cosas a la vez:

  • Cuánto tiempo necesitas los logs para depurar problemas activos.
  • Cuánto tiempo los necesitas para investigaciones de seguridad y trazabilidad de auditoría.
  • Qué exige tu situación de compliance, si tienes alguna.
  • Cuánto te cuesta cada mes extra de almacenamiento, en dinero y en rendimiento de consultas.

Cuando separas esas cuatro capas, el número mágico deja de tener sentido.

Dos enfoques: retención corta vs. retención larga

Retención corta (1–14 días)

En la práctica. Los logs viven en un backend rápido y consultable durante una o dos semanas y luego se eliminan. Lo importante ya se convirtió en una métrica, una alerta o un informe de incidente guardado.

Cuándo compensa:

  • Proyectos muy tempranos con poco tráfico y presupuesto ajustado.
  • Apps donde los logs solo sirven para depurar el bug de esta semana, no el del trimestre pasado.
  • Proyectos personales o secundarios donde el almacenamiento lo pagas de tu bolsillo.

Cuándo duele:

  • Pierdes contexto para bugs de incubación larga que solo aparecen tras unos días en producción.
  • Las investigaciones de seguridad se vuelven adivinanzas si el incidente se descubre tarde.
  • Chocas rápido con límites cuando un cliente pide “qué pasó con mi cuenta el mes pasado”.

Coste típico. Un SaaS pequeño con unos pocos servicios y volumen modesto puede mantener 14 días de logs calientes por muy poco — a menudo por debajo del precio de un café al mes en los niveles más básicos de la mayoría de servicios gestionados. El coste real aparece cuando crece el tráfico, no cuando crece la retención.

Retención larga (30–365+ días)

En la práctica. Mantienes logs consultables durante meses, o los envías a almacenamiento de objetos barato (nivel frío o archivo) para que la historia siga ahí técnicamente, aunque casi no se consulte.

Cuándo compensa:

  • Manejas datos regulados y necesitas demostrar disciplina de retención ante una auditoría.
  • Los clientes piden ocasionalmente historial de uso o de incidentes.
  • Estás creciendo rápido y quieres margen para hacer retrospectivas trimestrales de errores y comportamiento.

Cuándo duele:

  • El coste de almacenamiento crece más o menos linealmente con el volumen y el tiempo. El nivel frío es barato por gigabyte, pero un año de almacenamiento “barato” para una app con tráfico real sigue siendo una línea de gasto seria.
  • Buscar entre meses de logs se vuelve más lento y más caro si no separas caliente de frío.
  • Más retención puede dar una falsa sensación de seguridad: los logs antiguos solo sirven si tu búsqueda y filtrado son buenos para encontrar cosas dentro.

Coste típico. La mayor parte del gasto en retención larga no está en el nivel caliente. Está en el nivel de archivo, en el pipeline de ingestión o en las consultas que lanzas sobre datos históricos. El precio unitario es bajo; el volumen no.

Qué decide realmente la elección en un SaaS pequeño

En lugar de inventar un número, pesa algunas dimensiones que los equipos reales usan para dimensionar la retención:

Tiempo de descubrimiento. ¿Cuánto suele pasar entre que aparece un bug, un pico de errores o un patrón de abuso y alguien lo nota? Si tus usuarios reportan problemas en uno o dos días, con dos semanas de logs calientes te basta. Si algo se detecta solo en una revisión mensual, necesitas más.

Tiempo de resolución. Suma un margen para arreglar: unos pocos días como mínimo. Una regla útil: la retención caliente debería cubrir cómodamente tiempo de descubrimiento + tiempo de arreglo + un colchón de seguridad.

Criticidad. Cada parte de tu sistema puede tener su propia política. Los eventos de autenticación y los de pago merecen más retención que el ruido verboso de debug. La mayoría de equipos acaban con un esquema por niveles:

  • Ventana caliente corta para logs ruidosos de aplicación.
  • Ventana más larga para logs de seguridad y acceso.
  • Archivo frío largo o indefinido solo para lo que un auditor podría pedir.

Madurez. Una funcionalidad nueva se toca a menudo y se beneficia de retención caliente más larga mientras se estabiliza. Un endpoint estable que no cambia en meses puede permitirse retención más corta.

Exposición a compliance. Si tu SaaS maneja datos personales bajo GDPR, datos de pago bajo PCI-DSS o datos de salud bajo HIPAA, la retención no es opcional: la fija la regulación o tu auditor. Los fundadores solos rara vez entran en el terreno HIPAA a menos que se hayan metido a propósito en salud; el GDPR aplica de forma amplia pero gobierna sobre todo derechos de supresión y base legal, más que un número concreto de días de logs. SOC 2, en cambio, sí espera ver una política de retención documentada, aunque el periodo elegido sea corto.

Techo de coste. Decide de antemano cuánto te está permitido gastar al mes en almacenamiento de logs. Un patrón útil: “el gasto en logs no debería superar el X% del gasto de infraestructura”. Cuando el volumen te acerque a ese techo, acorta la ventana caliente, sube el nivel de log o empuja datos antiguos a frío.

Un punto de partida sensato para la mayoría de SaaS indie

Si no quieres darle muchas vueltas, esta es una configuración equilibrada que podrás ajustar más adelante:

  • Logs de aplicación y acceso: 14–30 días calientes y consultables. Cubre la mayoría de ciclos de depuración sin gastar mucho.
  • Logs de errores y excepciones: 30–90 días calientes si el almacenamiento te sale barato; si no, 14 días más un informe de incidente guardado.
  • Eventos de autenticación y seguridad: 90 días a 1 año, según regulación y expectativas del cliente.
  • Registros de auditoría y facturación: según regulación. A menudo entre 1 y 7 años, en almacenamiento frío resistente a manipulaciones, no en tu backend caliente.

La división importa porque meter todo en el mismo cubo o bien guarda demasiado (gasto inútil) o demasiado poco (evidencia perdida).

Pasos prácticos para configurarlo

  1. Haz inventario de lo que realmente estás logueando. Lista las categorías: logs de aplicación, de acceso, de errores, de autenticación, de auditoría. No puedes fijar retención por categoría hasta saber qué tienes.
  2. Estima tu volumen diario de ingestión. La mayoría de proveedores gestionados lo muestran en su panel. Multiplica por los días de retención previstos para hacerte una idea del crecimiento de almacenamiento.
  3. Define retención por niveles según la categoría. Usa gestión del ciclo de vida de índices, reglas de ciclo de vida de buckets, o lo que ofrezca tu plataforma, para expirar cada categoría con su propio calendario.
  4. Envía los datos antiguos a almacenamiento frío si los necesitas. Los niveles de archivo del almacenamiento de objetos son mucho más baratos por gigabyte que los backends calientes, a cambio de consultas más lentas. Úsalos para los datos que esperas no necesitar nunca.
  5. Pon un tope de gasto. Decide un techo mensual para almacenamiento e ingestión de logs. Cuando te acerques, acorta la ventana o haz muestreo de logs ruidosos antes de gastar más.
  6. Documenta la política. Incluso un párrafo en tu repo o runbook basta para la mayoría de conversaciones de compliance en fase temprana y te evita replantear esto cada trimestre.

Preguntas frecuentes

¿Son suficientes 30 días de logs para un SaaS pequeño? Para la mayoría de proyectos indie sin requisitos regulatorios, entre 14 y 30 días de logs calientes y consultables va bien. Para eventos de seguridad conviene más.

¿Necesito guardar logs durante un año? Solo si te lo pide una regulación, un contrato con un cliente o un auditor. Para la mayoría de productos SaaS de un fundador, un año de todos los logs es demasiado; un año de logs de seguridad y auditoría es más razonable.

¿Cuál es la forma más barata de conservar logs más tiempo? Exportar a niveles de archivo del almacenamiento de objetos (las opciones de archivo frío o profundo que ofrecen los principales proveedores cloud). El coste por gigabyte cae en picado. A cambio: las consultas son más lentas y cuestan más por petición.

¿Me obliga GDPR a guardar los logs X días? GDPR habla más de base legal y derecho de supresión que de un número concreto de días. Necesitas una política documentada y un motivo para el periodo elegido. “Guardamos X porque Y” es el listón.

¿Exige SOC 2 una retención larga? SOC 2 espera una política documentada con una razón defendible para la ventana elegida. No prescribe un número. Una política corta y bien documentada es aceptable.

¿Cuál es la primera señal de que mi ventana de retención es demasiado larga? Que la factura de logs crezca más rápido que el número de usuarios y que nadie del equipo consulte logs de más de dos semanas. Esa es la señal para recortar la ventana o mover datos antiguos a almacenamiento frío.

La conclusión

La retención no es una decisión moral. Es una decisión de presupuesto con consecuencias en depuración y compliance. Para un SaaS pequeño, la respuesta práctica es una política por niveles: retención caliente corta para logs ruidosos de aplicación, más larga para eventos de seguridad y archivo frío solo para lo que alguien podría llegar a pedirte que muestres. Empieza por ahí, apúntalo por escrito y revísalo cuando cambie el tráfico — o tu checklist de auditoría.

Fuentes