Skip to main content

​
Logs: the real-time event log viewer

Insights → Logs is a live, tail-style view of the events your workspace produces — sent and failed messages, webhook events, agent and voice activity — one row per event, newest at the top, refreshing roughly every 30 seconds. Use it for the operations question: “what is happening on my workspace right now, and what just failed?” That is a different question from the one the Request Logs console answers — Developer → Request Logs records every API call with its full HTTP payloads, while Insights → Logs watches the event stream behind the API. The two pair well, and this guide closes with the difference.

​
What the Logs page shows

Each row is one event:
  • Timestamp — the event’s real time, at millisecond precision so back-to-back events in a burst stay distinguishable, rendered in your own locale.
  • Severity — Success (green), Pending (amber), Failed (red), or Debug (muted), derived from the event’s status.
  • Service — the pillar the event belongs to: API, Webhook, Agent, or Voice.
  • Message — a short description of what happened.
  • Request ID — the correlating request id, when the event carries one. Keep this — support traces by request_id.
Above the list, four severity counters summarize the currently filtered set, so they move as you narrow. The list loads 50 rows at a time with a Load more button, auto-scrolls on new entries only while you are at the bottom (scroll up to read and the tail pauses — scroll back to the bottom and it resumes), and exports the current filtered set as CSV (orbit-logs-<date>.csv). A Refresh button re-queries on demand between the 30-second polls, and the Reset control clears every filter.

​
Where it lives, and who sees it

Open Insights → Logs in the dashboard — it is also a tile on the Insights hub and reachable from the command palette (⌘K, then type “Logs”). The page is role-gated to owner, admin, and developer: rows carry request ids and expandable event detail, and that metadata can contain personal data. Viewer, billing, and agent roles do not get the entry in navigation; the page refuses them if opened by URL. Manage which members hold those roles from your organization’s member settings. From any triage you run here you can jump to Settings → Audit log (linked in the page header) when the question turns from “what event happened” to “who changed what configuration.”

​
Filtering the stream

The filter bar narrows in four independent ways, and every combination is valid — filters AND together:
  • Severity — click a severity counter (Success, Pending, Failed, Debug) to isolate that level; click it again to clear. Isolate Failed to collapse noise during an incident.
  • Service — the API / Webhook / Agent / Voice chips keep events from one pillar. Pick Voice while debugging call behavior and the inbound-webhook queue disappears.
  • Search — free text against the message and the request id. Paste a request id straight from a response envelope’s meta.request_id (or from a Failed row) to jump to everything tied to that call; type webhook to watch deliveries; type a channel name such as voice to narrow to one lane.
  • Time range — 1h, 6h, 24h, 7d, 30d, 90d, or All. The range is sent to the server, so a wider window actually re-queries further back rather than re-slicing the list you already have. The page opens on All, which guarantees an idle workspace — one whose newest event is weeks old — never opens to a baffling empty list. Narrow from there: dropping to 1h visibly sheds older rows, which is the quickest way to confirm the control is working when the stream is busy.
Sample triage pass: isolate Failed, set the service to Webhook, drop the range to 6h, then paste the request id of the strangest row into search. Four filters, one answer.

​
Read a row, and pivot into the record it references

Click any row that shows a chevron (or press Enter/Space on it when focused) to expand the event’s structured detail as formatted JSON — the event metadata plus its request id. Values that look like personal data or credentials (phone numbers, authorization headers, tokens, emails) are masked as [redacted] in this panel before they render, so an expanded row is safe to read and to share with support. The detail panel is the starting point, though, not the destination:
  1. Copy the request id from the expanded row — it is the correlation token across the platform.
  2. Paste it into Developer → Request Logs (its Request ID filter) or into Developer → Delivery logs to land on the exact API call or delivery that produced the event, with full request/response payloads on the Request Logs side.
  3. Follow the referenced conversation or call. Events that originate from a conversation or a call carry it in their metadata — open Conversations or the call record from the referenced id and read the same moment from the customer’s side. That pivot — event row → request id → delivery — is the standard loop per event.
Export stays honest under filters: the CSV contains exactly the filtered set you are looking at, so scope first and hand the file to support second.

​
Logs vs Request Logs

Reach for Logs first in an incident; reach for Request Logs when the event filter points at one API call you need to dissect. For the API-call-versus-delivery gap, the developer-delivery-logs guide covers the second hop.

​
See also