Litmus Edge 4.4.x - System: Logs
Query System Logs
GET {{edgeUrl}}/logs/query?limit=100
Query the system journal across every LitmusEdge service. This is the API behind the Streaming Logs page in the web UI.
Not present on 4.0.x. The service answers on 4.2.x and 4.3.x with an identical build, so it arrived in 4.1.x or 4.2.x. On a device without it, every /logs/* path falls through to the web application shell and returns HTML with a 200, so check for a JSON body rather than for a 404 when you probe for availability.
| Response field | Meaning |
|---|---|
entries |
The matching log lines, newest first |
count |
Number of entries in this response |
cursor |
Timestamp to pass back to fetch the next page |
Each entry carries timestamp, level, message, component, and a fields object holding the underlying journald metadata (_PID, _COMM, _SYSTEMD_SLICE, SYSLOG_IDENTIFIER and similar).
| Parameter | Notes |
|---|---|
limit |
Defaults to 100 |
level |
error, warn, info and the other journald severities |
component |
Must be the exact service name, such as loopedge-dh. A partial name like analytics matches nothing and returns an empty list rather than an error |
search |
Free-text match against the message |
start |
Lower bound. See below |
cursor |
Upper bound. See below |
Paging runs in both directions from the same value. The response cursor is the RFC3339 timestamp of the newest entry in the page, and you feed it back into whichever parameter matches the direction you want:
| To do this | Send the returned cursor as |
Result |
|---|---|---|
| Tail for new lines | start |
Entries at or after that time. This is what the Streaming Logs page polls with |
| Page back through history | cursor |
Entries strictly before that time |
Both take an RFC3339 timestamp, not an opaque token and not an offset. Their validation differs: cursor=0 is rejected with 400, while start=0 is silently ignored and you get the unfiltered newest page back. An unrecognised parameter is ignored the same way, so confirm a filter actually applied by checking the entries rather than the status code.
message is the raw line as the service emitted it. Most LitmusEdge services log structured JSON, so the message is frequently itself a JSON document that needs a second parse; do not assume it is plain text.
Response
Status: 200 OK
{"entries":[{"timestamp":"2026-09-17T00:22:28.602598Z","message":"{\"level\":\"error\",\"_time\":\"2026-09-17T00:22:28.602Z\",\"logger\":\"processors\",\"_msg\":\"error during child calculate\",\"id\":\"C8D1A2A7-7F27-5035-A696-053754DC029D\",\"name\":\"Press06 recipe interlock\",\"function\":\"Tengo script processor\",\"error\":\"no compiled Tengo script\"}","level":"error","component":"loopedge-analytics2","fields":{"SYSLOG_FACILITY":"3","SYSLOG_IDENTIFIER":"loopedge-analytics2","_BOOT_ID":"<boot-id>","_CAP_EFFECTIVE":"0","_COMM":"loopedge-analyt","_EXE":"/usr/bin/loopedge-analytics2","_GID":"29790","_HOSTNAME":"litmus-edge-000000000000","_MACHINE_ID":"<machine-id>","_PID":"8394","_RUNTIME_SCOPE":"system","_STREAM_ID":"<stream-id>","_SYSTEMD_CGROUP":"/system.slice/loopedge-analytics2.service","_SYSTEMD_INVOCATION_ID":"<invocation-id>","_SYSTEMD_SLICE":"system.slice","_TRANSPORT":"stdout","_UID":"29790","hostname":"litmus-edge-000000000000"}},{"timestamp":"2026-09-17T00:22:28.596568Z","message":"{\"level\":\"error\",\"_time\":\"2026-09-17T00:22:28.596Z\",\"logger\":\"processors\",\"_msg\":\"error during child calculate\",\"id\":\"28ED7909-7DD7-5BB2-955C-5552E195CB34\",\"name\":\"Press05 recipe interlock\",\"function\":\"Tengo script processor\",\"error\":\"no compiled Tengo script\"}","level":"error","component":"loopedge-analytics2","fields":{"SYSLOG_FACILITY":"3","SYSLOG_IDENTIFIER":"loopedge-analytics2","_BOOT_ID":"<boot-id>","_CAP_EFFECTIVE":"0","_COMM":"loopedge-analyt","_EXE":"/usr/bin/loopedge-analytics2","_GID":"29790","_HOSTNAME":"litmus-edge-000000000000","_MACHINE_ID":"<machine-id>","_PID":"8394","_RUNTIME_SCOPE":"system","_STREAM_ID":"<stream-id>","_SYSTEMD_CGROUP":"/system.slice/loopedge-analytics2.service","_SYSTEMD_INVOCATION_ID":"<invocation-id>","_SYSTEMD_SLICE":"system.slice","_TRANSPORT":"stdout","_UID":"29790","hostname":"litmus-edge-000000000000"}}],"cursor":"2026-09-17T00:22:28.596568Z","count":2}
Get Logs Service Version
GET {{edgeUrl}}/logs/version
Version and build commit of the logs service.
Not present on 4.0.x. The service answers on 4.2.x and 4.3.x with an identical build, so it arrived in 4.1.x or 4.2.x. On a device without it, every /logs/* path falls through to the web application shell and returns HTML with a 200, so check for a JSON body rather than for a 404 when you probe for availability.
Useful as the availability probe for the whole surface: a JSON body means the service is installed, HTML means it is not.
Response
Status: 200 OK
{"version":"0.0.2","commit":"3b12cf2309"}