Sentry o Rollbar: cuotas y contexto del plan gratis

Sentry conviene si para resolver un fallo hay que relacionar la excepción con trazas, registros y la actividad previa del usuario. Rollbar merece prioridad cuando el trabajo consiste en ordenar errores repetidos, asignar incidencias y disponer de más repeticiones de sesión sin pagar. La comparación de StackFYI plantea esa diferencia como un criterio de elección, sujeto al volumen y al flujo de cada equipo.

Los planes gratuitos aceptan un volumen parecido de errores, pero distribuyen de otra forma las repeticiones y el contexto técnico. Una aplicación con pocos fallos puede caber en ambos; durante un despliegue problemático, miles de eventos duplicados pueden consumir la cuota aunque aparezcan reunidos en una sola incidencia. Por eso importan tanto los datos necesarios para investigar como la forma en que se cuentan.

Las cuotas que cambian la decisión

El plan Free de Rollbar incluye 5.000 ocurrencias y 1.000 repeticiones de sesión al mes, usuarios ilimitados y hasta 30 días de retención. La tarifa también incluye agrupación, alertas, trazas de pila, seguimiento de versiones y asignación de errores. Al llegar al límite mensual, la configuración predeterminada detiene el procesamiento de nuevos eventos; el consumo adicional exige otra modalidad de cobertura y puede generar cargos.

La ficha del plan Developer de Sentry, que remite a su tarifa, registra para una persona 5.000 errores, 50 repeticiones, 5 millones de spans y 5 GB de registros al mes. Son cuotas de categorías distintas: una repetición reconstruye una sesión, mientras los spans describen pasos de una traza y los registros conservan mensajes con contexto técnico. Tener más capacidad en una categoría no compensa automáticamente un límite en otra.

La diferencia de repeticiones favorece a Rollbar cuando muchas incidencias requieren observar la interacción anterior al error. Sentry ofrece, dentro de su plan gratuito, otras vías para seguir la ejecución. Las cifras tampoco demuestran que una repetición de cada producto capture exactamente lo mismo: la utilidad depende de la aplicación instrumentada y de la información que se permita registrar.

Qué hace la agrupación cuando un error se repite

Rollbar agrupa ocurrencias repetidas en una incidencia sin eliminar los eventos individuales.

La documentación de agrupación de Rollbar distingue la ocurrencia individual del item que reúne ocurrencias con una misma huella. Su objetivo es juntar fallos con una causa común y separar los que tienen causas diferentes. El producto permite ajustar las reglas de agrupación cuando el resultado predeterminado no representa bien los errores de una aplicación.

Esa distinción mejora la lectura de una bandeja ruidosa, pero una incidencia agrupada sigue formada por eventos individuales. Un fallo que se repite durante horas puede ocupar una sola fila para el equipo y, al mismo tiempo, consumir gran parte de la cuota de ocurrencias. La agrupación ayuda a decidir qué corregir; no reduce por sí sola el volumen enviado al servicio.

También puede fallar en ambas direcciones. Si causas distintas quedan juntas, asignar la incidencia a una persona puede ocultar otro defecto. Si un cambio de código separa ocurrencias de la misma causa, el equipo recibe varias incidencias para una corrección. Rollbar ofrece controles para ajustar ese comportamiento; Sentry también agrupa errores, de modo que la elección depende del resultado con excepciones representativas y del trabajo posterior de clasificación.

Dos aplicaciones y el efecto de un pico

En un ejemplo hipotético, una aplicación pequeña envía 300 errores y conserva 40 repeticiones de sesiones relacionadas durante un mes. Ambas cantidades caben en los planes gratuitos descritos. Si depura una sola persona y necesita seguir una solicitud entre servicios, los spans y registros de Sentry pueden responder preguntas que la excepción aislada deja abiertas. Si varias personas se reparten incidencias y revisan sesiones, el acceso incluido en Rollbar cambia la conveniencia del plan.

Supongamos que esa aplicación pasa a necesitar 120 repeticiones mensuales, sin aumentar los errores. Seguiría dentro de la cuota de Rollbar y superaría la de Sentry. El cambio no indica que Rollbar diagnostique mejor cada sesión: muestra que la cantidad de contexto disponible sin ampliar el plan depende de qué tipo de datos consume el equipo.

En otra aplicación hipotética, llegan 450 errores habituales y un fallo posterior a un despliegue produce 6.000 ocurrencias adicionales. El total sería de 6.450 eventos: supera en 1.450 la cuota gratuita de errores u ocurrencias de cada producto, aunque el fallo repetitivo aparezca agrupado. Bajo la modalidad predeterminada de Rollbar descrita antes, parte de los eventos dejaría de procesarse al agotarse el límite; para mantener la cobertura habría que cambiar de modalidad o de plan. En Sentry también habría que ajustar la captura o contratar más capacidad.

El cálculo separa dos preguntas que una media mensual mezcla: cuántas incidencias distintas habrá que resolver y cuántas veces llegarán sus eventos. Una aplicación tranquila puede cruzar el límite durante un pico breve. Reducir duplicados enviados puede proteger la cuota, pero el equipo necesita conservar suficientes ejemplos y datos de contexto para distinguir una repetición conocida de un fallo nuevo.

Cuánto cuesta añadir contexto

Sentry relaciona una repetición de sesión con trazas y registros para investigar un error.

Una traza ayuda a localizar el paso de ejecución en que surgió el problema; un registro puede mostrar el dato o mensaje que lo precedió; una repetición aporta la secuencia de interacción. En Sentry, esas piezas pueden quedar relacionadas con el error, pero capturarlas requiere instrumentación y consume cuotas separadas. La decisión económica cambia si una investigación necesita habitualmente esas relaciones o si una traza de pila y la versión desplegada suelen bastar.

La explicación de Sentry sobre los planes Developer heredados establece que el rastreo pasó de medirse por transacciones a medirse por spans, mientras el plan siguió siendo gratuito y las demás cuotas permanecieron iguales. Un span representa una parte de la ejecución, así que el número consumido por solicitud depende de lo que se instrumente. Comparar una antigua cuota de transacciones con la cuota vigente de spans como si fueran unidades equivalentes llevaría a una previsión errónea.

Rollbar concentra el cálculo inicial en ocurrencias y repeticiones, junto a un flujo de clasificación y asignación. Sentry añade categorías que pueden aportar la causa de un fallo sin consultar herramientas separadas, pero su utilidad exige capturar datos pertinentes. Para cualquiera de los dos servicios, enviar más contexto también obliga a decidir qué información de usuarios y solicitudes es apropiado conservar.

Elección según el flujo de trabajo

Para quien mantiene una aplicación pequeña y necesita conectar fallos con la ejecución de varios servicios, Sentry ofrece un punto de partida amplio. Rollbar resulta especialmente atractivo para un equipo que distribuye la clasificación de errores y depende de un mayor cupo gratuito de repeticiones. Ninguna de esas preferencias garantiza que el plan gratuito soporte un pico de ocurrencias.

La comparación más útil toma errores habituales, un fallo repetitivo y otro que requiera contexto adicional. Importa observar cómo se agrupan, qué información permite asignarlos y cuántos eventos, repeticiones, spans o registros consume la captura necesaria. Esas diferencias determinan tanto la capacidad de depuración como el coste de mantenerla cuando la aplicación crece.