1. Por qué necesitas métricas y SLO en una ChatGPT App
Imagina dos estados de un equipo.
En el primero, todos viven con el principio «parece que funciona». Mientras los usuarios no se quejen al soporte ni escriban tuits enfadados, todo ok. De vez en cuando alguien entra en los logs, hojea una «sábana» de líneas, asiente y cierra la pestaña.
En el segundo, el equipo tiene unos cuantos paneles sencillos:
- p95 de la latencia de la herramienta MCP principal.
- error‑rate para MCP y para el checkout.
- disponibilidad de los webhooks.
- conversión a pago a lo largo del embudo.
Y hay 3–5 SLO: «El 95% de las llamadas a la herramienta recommend_gifts — más rápido que 2 segundos», «la proporción de errores de MCP‑tools < 1%», «disponibilidad del checkout ≥ 99.5%», «conversión desde el widget hasta el pago correcto ≥ 10%».
En el segundo escenario tú:
- entiendes rápido que con la aplicación algo va mal, incluso antes de las quejas;
- puedes medir el efecto de cualquier cambio (nuevo algoritmo de recomendaciones, migración de SDK, nueva tarifa del proveedor);
- y para cuando llegues al módulo sobre el Store y la revisión, podrás decir honestamente: «tenemos criterios de calidad y sabemos en qué medida los cumplimos».
Hablaremos de cosas muy evidentes: qué es p95, por qué es mejor que la media, cómo calcular error‑rate y availability, qué métricas son importantes para la parte de commerce con webhooks y cómo con todo ello montar SLO simples pero útiles. Veremos todo esto en el ejemplo de nuestra aplicación didáctica GiftGenius — un escenario de commerce con herramienta MCP de recomendaciones, checkout y webhooks de pago.
2. Métricas básicas para una ChatGPT App: qué medir exactamente
Latencia: p50/p95/p99 en lugar de «la media que no dice nada»
La latencia es el tiempo desde el inicio de una operación hasta su final lógico. En nuestro stack hay varias operaciones así:
- la invocación de la herramienta MCP recommend_gifts (selección de regalos);
- la invocación de la herramienta que crea el intent de checkout en ACP;
- el procesamiento del webhook de pago correcto.
Es importante entender que la latencia total que ve el usuario en ChatGPT solo la controlamos parcialmente. Hay una parte de la plataforma (inferencia del modelo, latencias de red de OpenAI) y nuestra parte — herramientas, backend, BD y pasarela de pago. Para el SLI (Service Level Indicator — indicador de nivel de servicio medible) de latencia, normalmente se mide precisamente nuestra parte: desde la entrada de la solicitud en la App/MCP hasta la respuesta lista de nuestro servidor.
El tiempo medio de respuesta aquí engaña. Si el 90% de las solicitudes llega en 100 ms y el 10% en 5 segundos, la media será de aproximadamente medio segundo y la gráfica parecerá «verde». Pero uno de cada diez usuarios ve un parón de 5 segundos — el UX sufre notablemente.
Por eso se usan percentiles: p50 (mediana), p95, p99. p95 es el umbral por debajo del cual caen el 95% de las solicitudes. Como subrayan las guías de SRE, los percentiles «no dejan que los outliers se escondan en el valor medio» y hacen visible la vida de ese 5–10% de usuarios menos afortunados que siempre caen en la cola de la distribución.
La forma más sencilla de pensarlo es: p50 dice cómo vive el usuario «medio», y p95/p99 muestran cuánto sufre la gente paciente para la que «algo va lento» todo el tiempo.
Error‑rate: proporción de solicitudes fallidas
Error‑rate es la proporción de solicitudes fallidas respecto al total en un período. Las fuentes de datos suelen ser o bien logs estructurados, o bien métricas con labels status="success" | "error".
En nuestro stack hay varios error‑rate naturales:
- a nivel de MCP‑tools: la proporción de llamadas a recommend_gifts que terminaron en error (excepción, HTTP 5xx de una API externa, timeout);
- a nivel de ACP/checkout: la proporción de intentos de compra fallidos (error de API, indisponibilidad de la pasarela de pago);
- a nivel del manejador de webhooks: la proporción de webhooks cuya gestión terminó en error.
Truco: en una ChatGPT App hay errores «silenciosos». Por ejemplo, la herramienta MCP devolvió un error, el modelo se disculpa y continúa la conversación sin sacar el error técnico al encabezado. Formalmente ChatGPT muestra una respuesta «humana», pero desde el punto de vista de la fiabilidad tu stack ha fallado. Por eso, para el error‑rate es importante contar precisamente los estados de ingeniería, no la «respuesta final de UX de GPT».
Availability: disponibilidad de los servicios
Availability es el porcentaje de solicitudes atendidas correctamente en un período. Conceptualmente es el mismo error‑rate, pero con signo contrario: «cuántas exitosas» en vez de «cuántas fallidas». Ejemplo clásico: availability = successful_requests / total_requests * 100%.
Aplicado a nuestro stack:
- disponibilidad del servidor MCP: cuántas llamadas JSON‑RPC desde ChatGPT terminaron con una respuesta correcta en la última hora;
- disponibilidad del checkout‑API: qué proporción de llamadas a /api/checkout acabó en HTTP 2xx;
- disponibilidad del endpoint de webhooks: qué proporción de webhooks entrantes desde la pasarela de pago obtuvo de nuestra parte una respuesta correcta (normalmente HTTP 200).
Si en la documentación del proveedor de pagos prometen, por ejemplo, una disponibilidad del 99.9% y tú tienes 97%, lo más probable es que el problema no sea de ellos.
Métricas de comercio: conversión y embudo
GiftGenius es un escenario de commerce. Aquí importa no solo la parte técnica (respuestas rápidas, pocos errores), sino también el resultado de negocio — cuán a menudo las recomendaciones se convierten en pedidos pagados.
Aquí entra en juego el embudo de conversión:
- usuarios a quienes se les mostró el widget (view);
- usuarios que eligieron un regalo (selection);
- usuarios que hicieron clic en «iniciar compra» (checkout started);
- usuarios cuyo estado de pedido pasó a «pagado» (paid).
De este embudo se puede obtener la conversión «del widget al pago», y esto también es un SLI — un indicador medible de la calidad del servicio. Por ejemplo, «conversión de pagos correctos / usuarios que vieron el widget en un día = 7%». Si de repente aumenta la latencia, o el checkout a veces cae por timeout, el embudo empezará a estrecharse en lugares inesperados.
Si usas Instant Checkout
Todas las métricas de commerce descritas se aplican igualmente a Instant Checkout basado en Agentic Commerce Protocol. En este caso, en lugar de tu propio /api/checkout tienes un Agentic Checkout API estandarizado: ChatGPT llama a tus endpoints REST POST /checkout_sessions, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete (y opcionalmente — cancel y GET), recibiendo cada vez de tu parte el estado «real» de la cesta y del checkout.
Para las métricas no cambia nada: el p95 de latencia, el error-rate y la availability los calcularás no sobre un /api/checkout arbitrario, sino sobre estos endpoints estándar. SLO del tipo «p95 de latencia del checkout < 3 segundos, error-rate < 2%» se aplican simplemente a las llamadas de checkout_sessions, no a un API artesanal.
Un mundo aparte: métricas de webhooks
Los webhooks son eventos asíncronos (por ejemplo, payment_succeeded de la pasarela de pago) que hacen avanzar un pedido en su ciclo de vida. Si los webhooks se procesan mal, la app puede recomendar regalos muy bien, pero los pedidos «se quedarán colgados» con estado «esperando pago» o en algún estado indefinido.
Si no te integras directamente con Stripe/la pasarela de pago, sino mediante Instant Checkout, el papel de «webhooks de la pasarela de pago» lo toman los order events de Agentic Checkout: tu backend envía a OpenAI eventos como order.created y order.updated a una URL de webhook dedicada. Es exactamente la misma clase de entidad: eventos asíncronos de los que depende el estado final del pedido, solo que el destinatario no es tu frontend, sino ChatGPT.
En consecuencia, contarás las mismas métricas — success rate, latency, error-rate — no para los webhooks de Stripe, sino para tus webhooks de order events hacia OpenAI. En el SLO puedes escribir directamente «no menos del 99% de los eventos order.* se entregan y procesan correctamente en 7 días, p95 de la latencia de procesamiento < 500 ms» — y será un SLI/SLO correcto precisamente para Instant Checkout.
Para webhooks normalmente se observa:
- webhook success rate — proporción de webhooks cuya lógica de negocio terminó con éxito (incluyendo reintentos);
- webhook latency — tiempo desde la entrada del webhook hasta el fin del procesamiento;
- webhook error rate — proporción de casos en que el procesamiento del webhook terminó en error (falló la validación, la BD no está disponible, timeout, etc.).
Por ejemplo, puedes fijar SLO: «no menos del 99% de los webhooks se procesan correctamente en 7 días» y «p95 de la latencia de procesamiento del webhook < 500 ms».
3. Cómo medir técnicamente las métricas en GiftGenius
Pasamos de la teoría al código. Necesitamos entender dónde insertar las mediciones para luego agregar los datos en p95, error‑rate y otras métricas.
Para no traer a la lección un Prometheus o Datadog concretos, asumiremos que tenemos una función simple logMetric o logging de eventos JSON. Encima de esto, cualquier sistema de observabilidad construirá los gráficos necesarios.
Medimos la latencia de la herramienta MCP
Supongamos que tenemos un servidor MCP de GiftGenius en TypeScript y la herramienta recommend_gifts. Envolvemos la lógica de negocio con un temporizador:
// mcp/tools/recommendGifts.ts
import { logMetric } from "../observability/metrics"; // helper hipotético
export async function recommendGiftsTool(input: RecommendInput) {
const startedAt = performance.now(); // hora de inicio
try {
const result = await recommendGifts(input); // lógica de negocio
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "success",
});
return result;
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "error",
error_type: "exception",
});
throw error;
}
}
Aquí logMetric puede simplemente escribir un log JSON en stdout:
// observability/metrics.ts
export function logMetric(
name: string,
value: number,
labels: Record<string, string | number>
) {
// En realidad aquí iría el cliente de Prometheus/DataDog
console.log(
JSON.stringify({
type: "metric",
name,
value,
labels,
timestamp: new Date().toISOString(),
})
);
}
Con este enfoque obtienes un flujo de eventos tool_latency_ms, donde ya por los labels tool y status puedes calcular el p95 solo de las llamadas exitosas o, al contrario, ver cuánto duran las solicitudes que terminan en error.
Calculamos el error‑rate
De forma similar puedes registrar una métrica de errores aparte:
// dentro del mismo manejador de la herramienta
logMetric("tool_error_total", 1, {
tool: "recommend_gifts",
error_type: "external_api_timeout",
});
Y para las solicitudes exitosas:
logMetric("tool_success_total", 1, {
tool: "recommend_gifts",
});
Luego, en el sistema de métricas, construyes error_rate = tool_error_total / (tool_error_total + tool_success_total) para un período. Esto ya se agrega en el lado del sistema de métricas; en la aplicación lo importante es emitir eventos con cuidado.
Si quieres el minimalismo total, incluso puedes apañarte con logs sin un error_total aparte. Entonces el error‑rate se calcula a partir del campo status.
Métricas de checkout/ACP
Para el endpoint de checkout en Next.js la lógica es la misma: envolvemos el handler con un temporizador y contamos estados.
// app/api/checkout/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const body = await req.json();
const result = await createCheckoutSession(body); // llamada a ACP/Stripe
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "success" });
logMetric("checkout_total", 1, { status: "success" });
return NextResponse.json(result, { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "error" });
logMetric("checkout_total", 1, { status: "error" });
return NextResponse.json(
{ error: "Checkout failed" },
{ status: 500 }
);
}
}
Ahora ya puedes observar el p95 de checkout_latency_ms y el error‑rate de checkout_total. Con estos SLI es fácil fijar SLO del tipo «p95 < 3 segundos, error‑rate < 2%».
Métricas de webhooks
Y, por supuesto, los webhooks. Ya discutimos qué métricas importan (ver sección 2), ahora veamos cómo recogerlas en el código. Ahí es especialmente importante no solo el tiempo, sino el hecho de un procesamiento correcto: de lo contrario el usuario pagó, pero el pedido no pasó a «paid».
// app/api/webhooks/payment/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const payload = await req.text(); // datos en bruto
const sig = req.headers.get("stripe-signature") || "";
const event = verifyStripeSignature(payload, sig); // validación
await handlePaymentEvent(event); // actualizamos el pedido
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: event.type,
status: "success",
});
logMetric("webhook_total", 1, {
type: event.type,
status: "success",
});
return new NextResponse("ok", { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: "unknown",
status: "error",
});
logMetric("webhook_total", 1, {
type: "unknown",
status: "error",
});
return new NextResponse("error", { status: 500 });
}
}
Con estos eventos puedes definir SLI:
- webhook success rate = success / (success + error);
- p95 de webhook_latency_ms para payment_succeeded.
Y luego definir para ellos SLO, por ejemplo «el 99% de los webhooks se procesan correctamente en 7 días, p95 < 500 ms».
4. Estadística de percentiles: un poco más a fondo
Ya nos hemos apoyado varias veces en p50/p95/p99; veamos ahora un poco más formalmente qué significan exactamente. En la vida real los percentiles los calculará el sistema de métricas, pero es útil entender qué ocurre ahí.
El percentil pX es el valor por debajo del cual se encuentran X por ciento de las mediciones. Si ordenas el array de latencias de menor a mayor, p95 estará en la «cola», más cerca de los valores máximos. En código (por ejemplo, en Node, si quisieras calcular localmente un p95 para un conjunto de valores) puede verse aproximadamente así:
// función sencilla para calcular el percentil
export function percentile(values: number[], p: number): number {
if (values.length === 0) return 0;
const sorted = [...values].sort((a, b) => a - b);
const index = Math.ceil((p / 100) * sorted.length) - 1;
return sorted[Math.max(0, Math.min(index, sorted.length - 1))];
}
Esta función se puede usar en tests o en un script simple que juegue con los datos y muestre cuánto difiere el p95 de la media. En producción, esta funcionalidad la asumirán Prometheus, Datadog, New Relic y otros «adultos» del sector.
5. SLI, SLO y SLA: en lenguaje llano
Tres siglas que parecen intimidantes, pero en realidad son muy simples.
SLI — Service Level Indicator
SLI es un indicador concreto y medible, una fórmula. Por ejemplo:
- p95(latency) de la herramienta recommend_gifts en las últimas 24 horas;
- error‑rate de las herramientas MCP en los últimos 7 días;
- conversión widget → pago correcto por semana.
SLI no es un objetivo ni una promesa, es simplemente «el termómetro».
SLO — Service Level Objective
SLO es el objetivo para un SLI, básicamente la condición de «salud» del servicio. Por ejemplo:
- «p95(latency de recommend_gifts) < 2 segundos en una ventana de 7 días»;
- «error‑rate de todos los MCP‑tools < 1% en una ventana de 30 días»;
- «disponibilidad del checkout API ≥ 99.5% por trimestre»;
- «conversión desde el widget hasta el pago correcto ≥ 15% al mes».
Una buena práctica es medir primero el nivel actual y fijar un SLO un poco más estricto que lo que ya soportas; de lo contrario se convertirá en «misión imposible» o en «ya está bien».
SLA — Service Level Agreement
SLA ya no es un objetivo interno, sino un acuerdo externo con usuarios o socios. En el SLA se establecen compromisos (por ejemplo, «99.9% de uptime») y consecuencias del incumplimiento (compensación, penalizaciones, ampliación de la suscripción, etc.). El SLO a menudo es más estricto que el SLA, para dejar espacio al «presupuesto de errores».
En el marco de nuestro GiftGenius didáctico probablemente no necesites un SLA, pero es importante entender la escalera:
SLI → SLO → SLA
métrica → objetivo → promesa externa
Error budget (presupuesto de errores)
Error budget es, simplificando, el volumen admisible de «no perfección». Si tienes un SLO «disponibilidad 99.9% en 30 días», entonces el 0.1% es el presupuesto de errores que se puede «consumir» en:
- releases planificados con downtime;
- experimentos;
- incidentes imprevistos.
Cuando el presupuesto «se ha agotado» (por ejemplo, en el mes la disponibilidad resultó ser 99.5%), es hora de frenar nuevas features y arreglar la estabilidad.
6. Métricas específicas para GiftGenius: commerce + webhooks
Reunamos todo y veamos GiftGenius como un producto completo.
Embudo y conversión
Imaginemos un recorrido sencillo del usuario:
flowchart TD A[Abrió la app con el widget de GiftGenius] --> B[Recibió recomendaciones] B --> C[Eligió un regalo] C --> D[Pulsó 'ir al pago'] D --> E[Pago correcto]
Para cada paso podemos registrar un evento:
logMetric("funnel_step_total", 1, {
step: "widget_view",
});
logMetric("funnel_step_total", 1, {
step: "gift_selected",
});
logMetric("funnel_step_total", 1, {
step: "checkout_started",
});
logMetric("funnel_step_total", 1, {
step: "checkout_paid",
});
Luego, sabiendo el número de eventos en el paso widget_view y en checkout_paid, podemos calcular la conversión: paid / view * 100%. Y fijar un SLO: «conversión ≥ 10%». Si de repente la conversión cae al 3% y los SLI técnicos (latency/error‑rate) se ven normales, puede que el tema esté en el UX, en la instrucción para el modelo o en la calidad del feed de producto, pero no en la infraestructura.
Métricas de webhooks como parte de la conversión
Ya hemos hablado de las métricas técnicas de los webhooks y su implementación. Ahora es importante ligarlas a la conversión: para escenarios de commerce los webhooks son críticos. El usuario ve «el pago ha pasado», pero el estado final del pedido depende de lo rápido que tu backend reciba y procese payment_succeeded.
SLI para webhooks:
- webhook success rate;
- webhook latency p95;
- una disponibilidad burda webhook_endpoint_availability.
Si el success rate de los webhooks cae, estás perdiendo pedidos literalmente.
7. Alertas sencillas sobre SLO
Un sistema de alertado completo es un tema más cercano a módulos operativos, pero ya ahora podemos sentar la base.
La idea es enviar alertas no por cada error aislado, sino por la violación de un SLO. Es lo que a menudo se llama symptom‑based alerts — alertas atadas a síntomas de degradación del servicio: te interesa no «ocurrió un error», sino «el servicio empezó a funcionar sistemáticamente peor de lo prometido».
Ejemplos típicos:
- error‑rate de los MCP‑tools en los últimos 5 minutos > 2% con un SLO < 1%;
- p95(latency de recommend_gifts) en 10 minutos > 3 segundos con un SLO de 2 segundos;
- en los últimos 15 minutos no hay ningún checkout_paid exitoso — sospecha de caída de la integración;
- webhook success rate en 10 minutos < 95%.
El texto de la alerta debe ser humano, no «Alert: metric 123 > 456». Ejemplo de «aviso en Slack» para GiftGenius:
[ALERT][GiftGenius] High error rate on MCP tools:
error_rate = 3.2% (>1% SLO) for last 5 minutes.
Impact: part of users cannot receive gift recommendations.
Actions: check MCP logs and external gift API health.
Estos mensajes están ligados a los SLO y ayudan a la persona de guardia a entender rápidamente la magnitud del problema.
8. Mini práctica: diseñando SLO para GiftGenius
Intentemos formular un conjunto de SLO para nuestra aplicación. Esto se puede hacer incluso en papel, sin un sistema de métricas desplegado.
Ejemplo de «arranque»:
- Para la herramienta MCP principal recommend_gifts:
- SLI: p95(latency) de llamadas exitosas en los últimos 7 días.
- SLO: p95(latency) < 2 segundos.
- Para los errores de las herramientas MCP:
- SLI: error‑rate = errors / (errors + successes) en 30 días.
- SLO: error‑rate < 1%.
- Para el checkout API:
- SLI: availability = proporción de HTTP 2xx del total de solicitudes.
- SLO: availability ≥ 99.5% al mes.
- Para los webhooks de pago:
- SLI: webhook success rate.
- SLO: no menos del 99% de procesamiento exitoso de webhooks en 7 días; p95 de la latencia de procesamiento < 500 ms.
- Para el resultado de negocio:
- SLI: conversión widget → pedido pagado por mes.
- SLO: conversión ≥ 10–15% (según el nicho).
Incluso un conjunto pequeño así ya da un «esqueleto» para tomar decisiones: si lanzas una nueva versión del modelo, cambias el prompt o el algoritmo de recomendaciones y ves que p95 y error‑rate se mantienen dentro de los SLO, y la conversión sube — probablemente el experimento haya salido bien.
Si en lugar de tu propio endpoint de checkout usas Instant Checkout, entonces «checkout API» son de hecho las llamadas de Agentic Checkout (/checkout_sessions create/update/complete), y «webhooks de pago» son tus order events (order.created, order.updated) hacia OpenAI. Las métricas y las formulaciones de SLO permanecen iguales; solo cambia el protocolo concreto.
9. Errores típicos al trabajar con métricas y SLO
Error n.º 1: medir solo el tiempo medio de respuesta.
El valor medio es cómodo, pero peligroso. Enmascara fácilmente la cola de solicitudes lentas. En una ChatGPT App esto es crítico: incluso si la mayoría de usuarios lo reciben todo rápido, pausas regulares de 5–10 segundos para un porcentaje pequeño de personas se perciben como «la app siempre va lenta». Por eso, para la latencia usa siempre al menos p50 y p95, no solo la media.
Error n.º 2: confundir SLI, SLO y SLA en la cabeza y en la documentación.
A veces los desarrolladores escriben «nuestro SLA — p95 < 2 segundos», aunque esto no esté fijado en ningún sitio para usuarios externos ni vaya acompañado de obligaciones. En realidad eso es un SLO. SLA es un acuerdo con clientes donde hay consecuencias de las violaciones. Si lo mezclas todo, será difícil entender qué prometes realmente y a quién.
Error n.º 3: falta de vínculo entre alertas y SLO.
La trampa clásica es configurar alertas «para cada error», para cada timeout, para cualquier desviación de una métrica en 0.01. Como resultado, el ingeniero de guardia vive en un infierno de notificaciones y deja de mirarlas. Es mucho más útil construir alertas en torno a la violación de un SLO: si el error‑rate crece sustancialmente por encima del nivel objetivo o el p95 «se sale» de los límites, ahí sí tiene sentido despertar a la gente.
Error n.º 4: ignorar las métricas de los webhooks y las partes asíncronas.
Un problema aparte, pero ya familiar, es ignorar las métricas de los webhooks y de las partes asíncronas. Muchos equipos solo vigilan las respuestas HTTP de los API principales, pero no miran los webhooks y el procesamiento en background. En escenarios de commerce es justo ahí donde se esconden los bugs más molestos: el pago pasó, el webhook no se procesó, el pedido «se quedó atascado». Sin métricas de success rate y latency en los webhooks puedes pasarte mucho tiempo pensando que «todo funciona», hasta que los números en contabilidad y en la base empiecen a divergir seriamente.
Error n.º 5: SLO poco realistas o su total ausencia.
A veces se formulan SLO del tipo «100% de uptime» o «ningún error en absoluto». En la práctica es inviable y desmotiva al equipo. El extremo contrario es no formular SLO en absoluto y vivir en modo «parece estar bien». El término medio es empezar midiendo los SLI actuales, fijar un objetivo un poco más estricto pero alcanzable e ir endureciéndolo a medida que el sistema madura.
Error n.º 6: métricas solo por cumplir el expediente, sin vínculo con el producto.
También pasa: el sistema de métricas está lleno de gráficas, p95, p99, decenas de dashboards, pero nadie puede responder a una pregunta simple: «Si esta línea sube, ¿qué se ve afectado? ¿El usuario? ¿El dinero? ¿La reputación?» Especialmente en productos LLM es importante conectar los indicadores técnicos (latency, error‑rate) con las métricas de negocio (conversión, pagos correctos). Si no, la observabilidad se convierte en una tele bonita pero inútil.
GO TO FULL VERSION