Skip to main content
Logs en tiempo real
El API Playground está deshabilitado para este endpoint debido a la naturaleza de las conexiones SSE, que no son compatibles de forma universal con los navegadores.
string
requerido
La clave de API de tu cuenta. Puedes encontrarla en la configuración de tu cuenta.
Usa este endpoint siempre que necesites una vista en vivo de una aplicación en lugar de hacer polling: seguir el progreso de un deploy, ver los logs a medida que se escriben, o alimentar el gráfico de CPU/RAM de un panel sin bombardear Obtener Estado de la Aplicación u Obtener logs de la aplicación con un temporizador. Reemplaza a ambos mientras dura la conexión. Internamente, al abrir una conexión aquí se establece un único stream upstream en el cluster de la aplicación y se retransmite por SSE, con una reconexión interna transparente si ese upstream se cae. Como cada conexión abierta mantiene un socket durante hasta 10 minutos, las aperturas tienen un límite de tasa independiente de los límites de conexiones concurrentes descritos más abajo: 1 apertura cada 5 segundos por (usuario, aplicación), y 20 aperturas cada 10 segundos por usuario en todas las aplicaciones, seguidas de un enfriamiento de 30 segundos.

Parámetros

string
requerido
El ID de la aplicación cuyos logs quieres monitorear. Este ID se puede encontrar en la URL del panel de administración de tu aplicación.

Respuesta

string
Indica si la llamada fue exitosa. success si fue exitosa, error si no.
En caso de fallo, la respuesta incluirá un campo code junto con el estado de error, detallando la causa. Si la solicitud es exitosa, la respuesta será un stream text/event-stream que contiene el feed en tiempo real de la aplicación. Cada conexión dura hasta 10 minutos. Cada cuenta puede mantener 5 conexiones concurrentes en tiempo real (REALTIME_MAX_CONNECTIONS) y cada aplicación 30 entre todos los usuarios (REALTIME_MAX_CONNECTIONS_APP); superar cualquiera de los dos devuelve 429.

Estructura de los Server-Sent Events (SSE)

La respuesta es un stream continuo en formato text/event-stream. Cada mensaje se compone de un campo event y un campo data. Las estructuras varían según el evento, así que analiza los payloads de forma defensiva.

Tipos de evento

  • system: Señales a nivel de protocolo. La línea data es un único código en mayúsculas: REALTIME_CONNECTING | <sseId> al conectar, y luego cualquiera de REALTIME_TIMEOUT, REALTIME_DISCONNECTED, REALTIME_RECONNECT o REALTIME_ERROR.
  • logs: Una única línea de log cuyo primer carácter es un byte de identificación del stream: \x01 (stdout) o \x02 (stderr). Lee data.charCodeAt(0) (1 = stdout, 2 = stderr) y luego data.slice(1) para el texto. Una línea sin ese byte de prefijo es stdout.
  • status: Métricas del contenedor en vivo como una cadena JSON, aproximadamente un frame por segundo. El primer frame de cada (re)conexión es completo: { cpu, cpuLimit, ram: [usedMB, limitMB], status, netIO: { i, o, new: { i, o } }, bIO: { i, o }, uptime } (uptime es el tiempo de inicio en ms epoch; netIO.new son bytes por segundo). Cada frame posterior es reducido, y solo contiene { cpu, ram, netIO, bIO }: combina cada uno con el último frame completo, conservando el cpuLimit, status y uptime anteriores. Mientras este stream esté abierto, prefiérelo antes que sondear GET /v2/apps/{app_id}/status, que puede estar desactualizado hasta cerca de un minuto para una aplicación con un stream en tiempo real abierto.
  • error: Contiene un código de error como CONTAINER_NOT_FOUND.
En el ejemplo de abajo, \x01 / \x02 representan los bytes de prefijo crudos de stdout / stderr.

Errores comunes