La Pregunta Real No Es Qué Herramienta — Es Quién Está de Guardia a las 2 AM

Toda aplicación en producción falla. La diferencia entre una alerta medianoche y una mañana tranquila es si tienes seguimiento de errores antes de necesitarlo.

Para desarrolladores independientes y fundadores solitarios, la decisión entre un SaaS gestionado como Sentry y una alternativa autogestionada no se trata solo de precio — se trata de qué tipo de carga operativa estás dispuesto a cargar. Esta guía recorre ese intercambio honestamente, sin fingir que ninguno de los caminos es gratis.

Qué Hace Realmente el Seguimiento de Errores (y Qué No Hace)

Las herramientas de seguimiento de errores capturan excepciones en tiempo real, adjuntan trazas de pila y contexto de ejecución, agrupan ocurrencias duplicadas en un solo problema y te alertan cuando algo se rompe. Vinculan errores a releases y commits específicos para que sepas qué cambió. Ese es el trabajo.

Lo que no hacen: no capturan caídas que producen cero excepciones. Para eso necesitas monitoreo de disponibilidad — una herramienta diferente para una pregunta diferente. Los operadores solitarios maduros ejecutan ambos, pero comienzan con seguimiento de errores porque te dice qué en tu código se rompió, no solo que tu sitio está caído.

El Camino Gestionado: Sentry y el Modelo de Pago por Evento

Sentry es la respuesta por defecto para la mayoría de los equipos web y de backend. Tiene la cobertura más amplia de SDK, la experiencia más madura en source-maps y trazas de pila, y un flujo de trabajo que va desde la captura de errores hasta la resolución sin salir de la plataforma. Esa conveniencia tiene una estructura de costos que puede sorprenderte.

Los precios de Sentry se basan en eventos, no por usuario ni por proyecto. Un evento es cualquier error, transacción, replay o adjunto que la plataforma ingresa. El plan gratuito Developer incluye 5,000 errores por mes y 50 replays de sesión. El plan Team comienza en $26 al mes (facturado anualmente) e incluye 50,000 errores y 50 replays. El plan Business es $80 al mes con el mismo límite de 50,000 errores. Todo lo que exceda esos cupos se factura por uso.

El problema no son los seats — son los cupos. Un deploy ruidoso puede consumir tu asignación mensual. Un trabajo en segundo plano que reintenta y falla repetidamente genera eventos igual que un crash visible al usuario. El replay de sesión, aunque útil, cuenta contra el mismo límite.

Para un fundador solitario con un proyecto secundario de bajo tráfico, el plan gratuito de Sentry puede ser suficiente. Una vez que alcanzas tráfico de producción que genera errores consistentes, la matemática cambia rápido. Y si estás lanzando una app móvil con reportes de crash frecuentes, esos conteos de eventos suben más rápido de lo que la mayoría de desarrolladores independientes esperan.

El Camino Autogestionado: Tu Servidor, Tus Cupos, Tu Mantenimiento

El seguimiento de errores autogestionado significa ejecutar la herramienta en tu propia infraestructura. El intercambio es directo: cambias costos mensuales por evento por tu propio tiempo y costos de servidor.

GlitchTip es la opción más ligera. Habla el protocolo wire de Sentry, lo que significa que puedes mantener las bibliotecas cliente de Sentry que ya tienes en tu código y simplemente apuntarlas a tu propio servidor. Se ejecuta en una VPS pequeña con tan solo 512 MB de RAM. No hay Kafka, no hay ClickHouse, no hay cadena compleja de dependencias. Lo despliegas, apuntás tu SDK y dejás de pagar por evento.

Temps toma un enfoque diferente. También expone un DSN compatible con Sentry, así que la migración es literalmente cambiar una URL en tu configuración existente de SDK. Pero empaca analytics, replay de sesión, monitoreo de disponibilidad y deploys por git-push en un solo binario Rust. Es gratuito para autogestionar, lo que significa que obtenés más funciones que GlitchTip sin costo adicional — pero también asumís el mantenimiento de una pila ligeramente más compleja.

SigNoz e HyperDX son plataformas nativas de OpenTelemetry. Unifican errores con trazas y logs bajo un solo pipeline OTel. Este es un intercambio fundamentalmente diferente a un drop-in de DSN Sentry: ambos requieren instrumentar tu código con SDKs de OpenTelemetry en lugar de cambiar un DSN. Si ya estás invertido en el ecosistema OpenTelemetry, este camino tiene sentido. Si no lo estás, el costo de migración es real.

El Costo Oculto de Autogestionar: No Son Solo las Facturas del Servidor

Ejecutar tu propio tracker de errores suena simple hasta que sos el que lo parchea a las 2 AM porque una actualización rompió tus consultas de ClickHouse, o estás depurando por qué tu instancia autogestionada compatible con Sentry dejó de ingerir eventos después de un reinicio de Docker Compose.

La carga de mantenimiento varía según la herramienta. GlitchTip, al ser basado en Django y liviano, es comparativamente bajo en mantenimiento. Temps, con sus analytics y replay empacados, tiene más partes móviles. SigNoz e HyperDX, como plataformas completas de observabilidad, llevan la mayor carga operacional.

Para un fundador solitario, tu tiempo es el recurso más escaso. Cada hora dedicada a mantener tu pila de seguimiento de errores es una hora que no dedicás a producto, clientes o revenue. Eso no significa que autogestionar sea incorrecto — significa que debés ser honesto sobre qué estás comprando con esas facturas de servidor.

Cuándo Autogestionar Realmente Tiene Sentido

El seguimiento de errores autogestionado justifica su existencia en tres escenarios:

Residencia y control de datos. Si manejás datos sensibles de usuarios y necesitás mantener la información de errores en tu propia infraestructura — por cumplimiento, política de privacidad, o simplemente porque no confías en un tercero con tus trazas de pila — autogestionar es la respuesta. Ninguna plataforma gestionada puede igualar el control que tenés cuando los datos nunca salen de tu servidor.

Costo predecible a escala. Si tu volumen de errores es alto y consistente, autogestionar generalmente se vuelve más barato que los precios gestionados. Una VPS de $10 al mes maneja muchos más eventos que el plan gratuito de Sentry, y no te sorprendés con un pico en fallos de trabajos en segundo plano. El costo es predecible porque es fijo.

Ya ejecutás infraestructura. Si te sentís cómodo gestionando contenedores Docker, manteniendo las actualizaciones y resolviendo problemas a horas extrañas, autogestionar es una extensión natural de lo que ya hacés. El costo marginal de agregar otro contenedor es bajo cuando ya tenés el hábito.

Cuándo el SaaS Gestionado es la Elección Correcta

El seguimiento de errores gestionado es la opción correcta cuando:

Querés enviar producto, no mantener infraestructura. Si tu producto es tu código, no tu infraestructura, un servicio gestionado te permite enfocarte en lo que construiste. Sentry, Rollbar, Bugsnag y Honeybadger manejan toda la carga operacional para que vos no tengas que hacerlo.

Tu volumen de errores es bajo e impredecible. Si sos un fundador solitario con un proyecto secundario que recibe errores ocasionales, pagar $26 al mes por el plan Team de Sentry suele ser más barato que el tiempo que invertirías configurando y manteniendo una instancia autogestionada. La matemática favorece a lo gestionado cuando los eventos son infrecuentes.

Necesitás profundidad móvil o multiplataforma. Bugsnag es el especialista para móvil y salud de releases, con symbolication nativa de clase líder y scoring de estabilidad. Si tu app corre en iOS y Android, las herramientas gestionadas mobile-first a menudo superan a las opciones autogestionadas fuera de la caja.

Ya estás en una plataforma. Si usás Datadog para APM o New Relic para monitoreo, su seguimiento de errores es una capa en una pila más amplia. Agregar una herramienta separada crea sobrecarga de cambio de contexto. Quedarte nativo mantiene tu observabilidad unificada.

Un Marco de Decisión Práctico

Antes de elegir, respondé dos preguntas:

Cuál es el centro de gravedad de tu stack. ¿Web-first (JavaScript, Python, Ruby, Go, PHP)? Sentry o una opción autogestionada compatible con Sentry es la opción natural. ¿Mobile-first (iOS, Android, React Native, Flutter)? Bugsnag merece consideración seria. ¿Ya estás en una plataforma de observabilidad? Quedarte nativo probablemente tenga sentido.

Cuál es tu verdadero cuello de botella. ¿No podés ver los errores? Cualquier herramienta lo resuelve — elegí por ajuste de stack y precio. ¿Te ahogás en ruido de errores? Necesitás agrupamiento inteligente y flujo de triaje — Rollbar y Honeybadger son afilados aquí. ¿No podés saber si un release es saludable? Necesitás salud de release y scoring de estabilidad. ¿El gasto en errores es muy alto? Necesitás una herramienta enfocada, no una plataforma — las herramientas standalone son casi siempre más baratas a volumen que las plataformas completas de observabilidad.

La Realidad de la Migración

Si estás actualmente en Sentry y considerando autogestionar, la migración es más simple de lo que pensás — si elegís la herramienta correcta. GlitchTip y Temps aceptan DSNs compatibles con Sentry, lo que significa que cambiás una URL en tu configuración de SDK y tus datos de errores comienzan a fluir a tu propio servidor. Tu código SDK existente permanece intacto. La transición es un cambio de configuración, no una reescritura.

Si estás considerando SigNoz o HyperDX, la migración es más profunda. Necesitarías reinstrumentar tu código con SDKs de OpenTelemetry. Eso es un esfuerzo de ingeniería real, no un cambio de URL. Incluílo en tu decisión.

La Conclusión

No hay un ganador universal. La elección correcta depende de tu volumen de errores, tu stack, tu tolerancia al trabajo operacional y cuánto valorás el control de datos versus la conveniencia.

Si sos un fundador solitario enviando una app web con tráfico moderado y errores ocasionales, el plan gratuito de Sentry o un plan gestionado de bajo costo como Honeybadger puede ser todo lo que necesitás. Si tu volumen de errores es alto, tus datos son sensibles, o ya te sentís cómodo ejecutando infraestructura, autogestionar con GlitchTip o Temps es una elección racional que se paga sola en costos predecibles y control total.

La peor decisión es comprar una plataforma cuando necesitabas un especialista, o un especialista cuando necesitabas la plataforma. Sabé qué estás optimizando — tiempo, costo o control — y elegí la herramienta que coincida con esa prioridad.

FAQ

¿El seguimiento de errores autogestionado es realmente gratis? El software es gratuito, pero pagás con costos de servidor y tu tiempo. Una VPS de $5–10 al mes cubre la infraestructura, pero calculá las horas que dedicarás a desplegar, actualizar y solucionar problemas. Para un fundador solitario, ese tiempo tiene un costo de oportunidad real.

¿Puedo cambiar de Sentry a una herramienta autogestionada sin reescribir mi código? Con GlitchTip o Temps, sí. Ambos aceptan DSNs compatibles con Sentry, así que cambiás una URL y mantenés tu integración SDK existente. Con herramientas nativas de OpenTelemetry como SigNoz, necesitarías reinstrumentar tu código.

¿Cuál es la opción más barata para un desarrollador solitario con bajo volumen de errores? El plan gratuito Developer de Sentry (5,000 errores por mes) es el punto de partida más económico. Si necesitás un poco más de margen, los planes de tarifa plana de Honeybadger ofrecen precios predecibles sin sorpresas de facturación por eventos.

¿Autogestionar realmente ahorra dinero con volúmenes bajos de eventos? Generalmente no. Si generás menos de 10,000 errores por mes, el costo del servidor más tu tiempo de mantenimiento generalmente excede lo que pagarías en un plan gestionado. Autogestionar justifica su existencia con volúmenes más altos y consistentes.

¿Qué hay del replay de sesión — lo necesito? El replay de sesión es útil para entender el recorrido del usuario que llevó a un error, pero cuenta contra tu cupo de eventos en la mayoría de las plataformas gestionadas. Si el replay es importante para vos, una opción autogestionada como Temps que lo empaca sin facturación por evento puede valer la pena el intercambio operacional.

Fuentes