La frescura de telemetría mide cuanto tiempo ha pasado desde la última señal valida de un expert advisor. En MT5 en vivo, un EA silencioso puede significar VPS caida, terminal congelado, error de red o experto detenido manualmente. Sin SLA de frescura, tu dashboard muestra el último valor conocido como si fuera actual, ocultando riesgo operativo.

Define una ventana máxima por clase de estrategia. Scalpers en M1 pueden requerir frescura de uno a dos minutos; swing en H4 pueden tolerar quince. Lo importante es que el umbral este documentado y alerte antes de que el operador asuma que todo funciona.

Cuando la telemetría se vuelve obsoleta, el sistema debe cambiar de estado visible: marcar el experto como STALE, dejar de calcular métricas derivadas confiadas y opcionalmente escalar severidad si persiste. Ocultar stale detrás de un icono gris tenue es un fallo de diseño.

La frescura debe medirse en el servidor de ingestión con reloj sincronizado, no solo confiar en timestamps del cliente. Desviaciones de reloj en VPS baratas son comunes. Valida skew y rechaza payloads con timestamps futuros imposibles.

Combina frescura con heartbeat explícito incluso sin operaciones. Un EA sano puede no operar durante horas pero debe emitir pulso de vida indicando que el terminal sigue conectado y el experto activo.

Las alertas por frescura deben incluir contexto: cuenta, bróker, simbolo principal, última operación conocida, versión del agente. Eso reduce tiempo de diagnóstico cuando gestionas decenas de cuentas.

No confundas frescura de telemetría con latencia de mercado. Puedes tener datos frescos de un EA que opera mal. La frescura solo garantiza que ves el mal comportamiento a tiempo.

Para cumplimiento prop firm, demostrar continuidad de telemetría durante sesiones activas refuerza que no hubo periodos opacos donde se cambiaron parámetros fuera de vista.

Automatiza runbooks: a los cinco minutos STALE envía Slack, a los quince minutos abre ticket, a los treinta minutos escala a operador de guardia si la cuenta es crítica.

Quantisentry documenta contratos de telemetría y expone endpoints de solo lectura para consultar última actualización por cuenta y experto, facilitando SLAs claros con clientes y equipos internos.

Diseño de SLA prácticos

Ejemplo de umbrales por criticidad

Clasifica cuentas en crítica, estándar y sandbox. Crítica usa ventanas cortas y páginas on-call; sandbox tolera retrasos más largos para no generar ruido. Revisa umbrales trimestralmente según estabilidad real de VPS y bróker.

Pública el SLA internamente para que desarrollo no prometa frescura subsegundo si la arquitectura entrega minutos.

Telemetría obsoleta y decisiones de riesgo

Nunca tomes decisiones automáticas de riesgo sobre datos stale. Si un modulo heredado calcula salud de cuenta con telemetría vieja, desactiva esas métricas o muestrelas atenuadas. La honestidad visual previene falsas tranquilidades.

Preguntas frecuentes

¿Que es telemetría obsoleta?

Datos cuya edad supera el SLA definido para esa cuenta o estrategia.

¿Debo alertar en fines de semana?

Si la cuenta debe permanecer conectada; si no, usa ventanas de mantenimiento silenciadas.

¿Confiar en timestamp del EA?

Valida en servidor; rechaza skew extremo y timestamps futuros imposibles.

¿La frescura implica rentabilidad?

No. Solo indica que ves el estado actual; un EA puede ser fresco y perder.