> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Logs: the real-time event log viewer > Open the dashboard's Insights → Logs page to watch your workspace's events as they happen — filter by severity, service, search text, and time range, then expand any row to read its payload. # 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](/guides/api-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-.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 | | Insights → Logs (this page) | Developer → Request logs | | -------- | ------------------------------------------------ | --------------------------------------------------------------------- | | Question | What is happening on the workspace now? | What exactly did my integration send and receive? | | Data | Activity events — message, webhook, agent, voice | API calls with full HTTP request/response payloads | | Audience | Operations / live triage | Developers debugging an integration | | Filters | Severity, service, text, time range | Method, status, path, key, request id, date range | | Live | 30-second refresh + tail | Live-tail SSE stream toggle + [Log-tail API](/api-reference/log-tail) | 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](/guides/developer-delivery-logs) covers the second hop. ## See also * [Read the Insights dashboards](/guides/insights-dashboards) — the wider Insights family the Logs tile sits in. * [Request Logs console](/guides/api-request-logs-console) — the developer-side HTTP twin of this page. * [Developer delivery logs](/guides/developer-delivery-logs) — what happened to a message after the API accepted it. * [Audit log](/guides/audit-log) — actor and configuration history, linked from the Logs header.