Vale la pena una pregunta antes de tu próxima renovación: si mañana duplicaras tu equipo de ingeniería pero no cambiaras nada de tu infraestructura, ¿debería subir tu factura de observabilidad?

Bajo el modelo de pricing dominante, sube, y a veces mucho. No es un accidente ni un bug. Es la forma en la que se vende la mayoría de las herramientas de observabilidad, y una vez que ves la forma ya no puedes dejar de verla. Este post va sobre esa forma: quién cobra así, por qué es racional para ellos, cuándo es de verdad justo, y cómo se ve cuando la factura sigue a tu infraestructura en lugar de a tu organigrama.

El modelo dominante: por usuario, por host, más datos

Abre la página de precios de casi cualquier vendedor grande de observabilidad y encontrarás alguna combinación de tres medidores:

Por host / por nodo. Pagas por cada host, agente o nodo monitoreado. Este es defendible: sigue, más o menos, cuánto corres.
Por usuario activo / por asiento. Pagas por cada persona que hace login. Grafana Cloud, por ejemplo, mide usuarios activos en sus tiers de pago; Datadog añade cargos por asiento en productos como APM, CI y su suite de seguridad.
Por volumen de datos. Logs ingeridos, métricas custom, spans retenidos, eventos indexados. Este es el medidor que se infla en silencio.

Nada de esto hace a Grafana o Datadog malos productos. Son excelentes: Grafana es la mejor capa de visualización de la industria, y la amplitud de Datadog es genuinamente útil si monitoreas VMs, serverless, bases de datos y Kubernetes desde un solo panel. La crítica aquí no es la calidad. Es que dos de esos tres medidores (asientos y datos) están solo débilmente correlacionados con el valor que recibes, y fuertemente correlacionados con el crecimiento y la verborrea de tu equipo.

Una nota sobre los números antes de seguir: el pricing de los vendedores cambia constantemente y varía por plan, región y negociación. Al momento de escribir, los tiers por usuario publicados para observabilidad hosteada suelen arrancar en algún punto entre los diez y los treinta y tantos dólares por usuario al mes, y los tiers por host en un rango parecido por host. Trata cada cifra de este post como ilustrativa: revisa la página de precios vigente del vendedor para cotizaciones reales. El argumento no depende del monto exacto. Depende de la pendiente.

El mismo cluster, dos equipos: dónde diverge la factura

Hagámoslo concreto. Imagina dos empresas corriendo exactamente la misma infraestructura: un cluster de producción, 10 nodos, un volumen estable de logs y métricas. La única diferencia es el tamaño del equipo que le mete mano.

Empresa A es un equipo de 3 personas. Tres logins, tres asientos.
Empresa B es un equipo de 30 personas. El mismo cluster, pero platform engineers, devs de backend, la rotación de guardia y un par de managers tienen acceso.

Bajo un modelo por usuario, la Empresa B paga por los mismos 10 nodos más 10 veces los asientos. Su sistema no es más complejo. Su factura de infraestructura con el proveedor cloud es idéntica. Pero su factura de observabilidad diverge, no porque monitoreen más, sino porque más humanos pueden ver los dashboards.

Aquí está lo perverso: la Empresa B está haciendo lo correcto. Quieres más ingenieros mirando producción. Quieres que la dev junior revise un dashboard antes de preguntar, que el ingeniero de backend se autoservicie un trace en vez de pingear a la guardia, que toda la rotación tenga acceso real durante un incidente. El pricing por asiento le pone precio justo a ese comportamiento, así que los equipos racionan logins, comparten cuentas (contra el ToS), o deciden en silencio que la observabilidad es un privilegio de unos pocos. Ese es un mal resultado disfrazado de control de costos.

La economía: por qué los incumbentes cobran así (y no van a parar)

Es tentador leer el pricing por asiento como codicia. Es más útil leerlo como diseño racional del vendedor.

El precio por asiento tiene tres propiedades que un modelo de ingresos de empresa pública adora. Es predecible: los asientos crecen despacio y pegajoso, así que el ingreso es pronosticable. Es amigable a la expansión: cuando el equipo del cliente crece, el ingreso crece solo, con cero esfuerzo comercial extra (la “net revenue retention” es la métrica que premian los inversores). Y es legible: un CFO entiende “$X por persona” al instante, aunque el valor de fondo sea el volumen de datos.

Para una plataforma amplia y generalista esto incluso tiene una lógica de justicia: una empresa de 30 personas probablemente sí extrae más valor total de una suite de observabilidad que lo hace todo que una tienda de 3 personas. El vendedor está, a grandes rasgos, cobrando por valor.

El punto no es que esto sea malvado. El punto es que es estructural. Un vendedor cuyo ingreso está construido sobre asientos y volumen de datos no puede cambiar a cobrar puramente por tu infraestructura sin abrir un hueco en su propio pronóstico. Así que no lo hará, y esa es la decisión correcta para ellos. Solo vale la pena saber que el modelo optimiza la predictibilidad de ingresos del vendedor, y que tu factura atada al headcount es un efecto secundario, no un objetivo.

Qué cobra KubeBolt: por recurso

KubeBolt toma el tercer medidor (el honesto) y suelta los otros dos.

Cobramos por recurso: tu factura sigue a la infraestructura que de verdad corres, los nodos y workloads bajo gestión. No sigue cuánta gente hace login. Invitar a todo tu equipo no cuesta nada extra. La empresa de 30 personas y la de 3 corriendo el mismo cluster pagan lo mismo, porque están corriendo lo mismo.

Dos hechos más que se derivan de esto, ambos vivos hoy, no “próximamente”:

El agente open-source es gratis para siempre bajo Apache 2.0: clusters ilimitados, nodos ilimitados, usuarios ilimitados, en tu propia infra. Trae tu propia clave de IA y el Copilot también es ilimitado.
El tier hosteado tiene un plan gratis disponible ya, así que puedes correr KubeBolt Cloud sin una calculadora de asientos en la primera conversación.

¿Por qué podemos hacer esto cuando los incumbentes no? En parte por foco: hacemos una cosa, operaciones de Kubernetes, así que nuestros costos siguen a tu cluster, no a un backend multi-señal desparramado. Y en parte porque diseñamos el modelo de ingresos alrededor de esto desde el día uno, en vez de acoplarlo sobre un negocio basado en asientos. La ventaja del recién llegado es no tener nada que proteger.

La parte honesta: cuándo el precio por usuario sí tiene sentido

Este sería un post barato si fingiera que el pricing por asiento siempre está mal. No lo está. Hay casos reales donde es el modelo más justo:

El valor sí es por persona. Para una herramienta de BI, una suite de diseño o un CRM, el asiento es la unidad de valor: cada usuario hace un trabajo distinto e individual. Cobrar por asiento ahí es honesto.
Infra chica, equipo grande. Si corres casi nada de infraestructura pero tienes una organización grande metiéndole mano, un modelo por recurso podría, en teoría, cobrar de menos frente al valor entregado. El por asiento captura eso.
La predictibilidad vale más para ti que la justicia. Algunos equipos de finanzas genuinamente prefieren una factura que mapee al headcount porque el headcount es fácil de pronosticar y gobernar. Esa es una preferencia legítima, no un error.
Gobernanza y control de acceso. En entornos regulados, “quién tiene un asiento” es en sí una lista controlada, y la facturación por asiento incidentalmente refuerza la disciplina de acceso.

Si caes en uno de esos cubos, el precio por usuario puede ser exactamente lo correcto para ti. El argumento aquí es más estrecho que “asientos malos”: es que para tooling de infraestructura, donde el valor escala con el sistema y no con el login, el headcount es el medidor equivocado.

Mapéalo a tu propio setup

Aquí va una tabla de escenarios ilustrativa. Los números son cifras redondas inventadas para mostrar la forma, no cotizaciones: mete el pricing real de tu vendedor para hacerlo exacto.

Escenario	Nodos	Ingenieros	Modelo por usuario (ilustrativo)	Modelo por recurso (ilustrativo)
Startup pequeña	5	3	~$45/mes asientos + host y datos	sigue solo 5 nodos
La misma startup, contratando	5	12	~$180/mes asientos + host y datos	sin cambio: siguen 5 nodos
Scale-up	20	30	~$450/mes asientos + host y datos	sigue solo 20 nodos
Equipo enterprise, infra plana	20	80	~$1,200/mes asientos + host y datos	sin cambio: siguen 20 nodos

Lee las filas de arriba abajo dentro de una empresa. Bajo la columna por usuario, la factura trepa cada vez que contratas, aunque el número de “Nodos” nunca se mueva. Bajo la columna por recurso, la factura solo se mueve cuando se mueve tu infraestructura. Una de esas columnas te premia por crecer el equipo. La otra te grava por hacerlo.

La pregunta estratégica para ti no es “qué vendedor es más barato hoy”. Es “¿a qué medidor quiero atada mi factura los próximos tres años?” Si tu equipo va a crecer más rápido que tu cluster (y la mayoría de los equipos sanos lo hace), el medidor importa más que el precio de lista.

Si el precio por recurso es la forma que quieres, nuestra página de precios muestra los tiers, incluyendo el agente OSS gratis para siempre y el tier hosteado gratis, sin matemática de asientos. Y si prefieres solo probarlo, el agente se instala en cerca de un minuto: invita a todo el equipo cuando quieras. No cambiará la factura.