Get Latest Performance
Changed onThe most recent snapshot of every scope in one subject, newest first.
One row per scope -- per (bot, controller), or per executor -- in the same normalized shape /history returns, so a dashboard's live tiles and its charts read the same fields off the same client.
limit caps how many scopes come back, it is not a page boundary: there is no cursor here because this is not a series. Newest-first ordering means the scopes that are still reporting come first, which matters far more for executors than for controllers -- every executor that ever ran leaves a terminal row behind, so the executor population grows without bound while the controller one does not.
This reads the stored series, not live memory. An executor younger than one snapshot interval has no row yet and does not appear, and a live one's figures are up to one interval stale -- by design, so that this row and the last row of /history are the same row. Live in-memory figures are what /executors/ serves.
A closed executor's latest row is its terminal row, carrying is_terminal: true and its close_type, so "the final value" needs no separate call. That holds for every way an executor can close, including the startup reap of one a crash left behind (close_type: SYSTEM_CLEANUP): this row and GET /executors/{executor_id} are written in the same transaction, so the two surfaces cannot disagree about whether an executor is done.
Request
- Base URLhttp://localhost:8000
- URLhttp://localhost:8000/performance/latest
- AuthHTTP basic
Query parameters
Which population to read: "controller" or "executor"
Filter by bot name (controller subject only)
Filter by controller ID (either subject)
Filter by executor ID (executor subject only)
Filter by executor type (executor subject only)
Filter by account name (executor subject only)
Filter by connector (executor subject only)
Filter by trading pair (executor subject only)
Cap on how many scopes come back, newest first
Response
Successful Response
Changes
- info
endpoint added
- info