Skip to main content
Real-time Logs
The API Playground is disabled for this endpoint due to the nature of SSE connections, which are not universally supported by browsers.
Authorization
string
required
The API key for your account. You can find this in your account settings.
Use this endpoint whenever you need a live view of an application instead of polling: watching a deploy progress, tailing logs as they are written, or driving a dashboard’s CPU/RAM graph without hammering Get Application Status or Get Application Logs on a timer. It replaces both for the duration of the connection. Internally, opening a connection here dials a single upstream stream on the application’s cluster and relays it back over SSE, with one transparent internal reconnect if that upstream drops. Because each open connection holds a socket for up to 10 minutes, opens are rate limited separately from the concurrent-connection caps described below: 1 open every 5 seconds per (user, application), and 20 opens every 10 seconds per user across all applications, with a 30-second cooldown after that.

Parameters

app_id
string
required
The ID of the application whose logs you want to monitor. This ID can be found in the URL of your application’s management panel.

Response

status
string
Indicates whether the call was successful.. success if successful, error if not.
In case of failure, the response will include a code field along with the error status, detailing the cause. If the request is successful, the response will be a text/event-stream stream containing the application’s realtime feed. Each connection lasts up to 10 minutes. Each account may hold 5 concurrent realtime connections (REALTIME_MAX_CONNECTIONS) and each application 30 across all users (REALTIME_MAX_CONNECTIONS_APP); exceeding either returns 429.

Server-Sent Events (SSE) Structure

The response is a continuous stream in text/event-stream format. Each message is composed of an event field and a data field. Shapes vary by event, so parse payloads defensively.

Event Types

  • system: Protocol-level signals. The data line is a single uppercase code: REALTIME_CONNECTING | <sseId> on connect, then any of REALTIME_TIMEOUT, REALTIME_DISCONNECTED, REALTIME_RECONNECT, or REALTIME_ERROR.
  • logs: A single log line whose first character is a stream-id byte: \x01 (stdout) or \x02 (stderr). Read data.charCodeAt(0) (1 = stdout, 2 = stderr), then data.slice(1) for the text. A line without that prefix byte is stdout.
  • status: Live container metrics as a JSON string, about one frame per second. The first frame of each (re)connection is complete: { cpu, cpuLimit, ram: [usedMB, limitMB], status, netIO: { i, o, new: { i, o } }, bIO: { i, o }, uptime } (uptime is the start time as epoch ms; netIO.new is bytes per second). Every later frame is lean, carrying only { cpu, ram, netIO, bIO } — merge each onto the last complete frame, keeping the previous cpuLimit, status, and uptime. While this stream is open, prefer it over polling GET /v2/apps/{app_id}/status, which can be up to about a minute stale for an app with an open realtime stream.
  • error: Carries an error code such as CONTAINER_NOT_FOUND.
In the example below, \x01 / \x02 stand for the raw stdout / stderr prefix bytes.

Common errors