Once real users are in your app, someone will report "the call didn't connect" or "chat stopped working". This page explains what Livqeno records about your project, so you can answer what happened, to whom, and why without asking the user to reproduce it.
You can read this data in three places:
| Where | Best for |
|---|---|
| The dashboard | Looking at one incident by hand. |
The CLI (livqeno diagnostics, livqeno errors list) | Quick checks from a terminal during an incident. |
| The Observability API | Your own monitoring and alerting tools. Called from your backend with the project API key. |
Errors are always shown as Livqeno errors, with a plain explanation. You never see raw media-server, relay, or database errors. See Error Codes.
What is tracked
| What | Details |
|---|---|
| Connections | One row per RTC participant session: state, region, SDK version, platform, and reconnect count. Once the client sends them, also real quality stats: RTT, jitter, packet loss, bitrate, and codec. See Diagnostics. |
| Errors | Grouped into categories like TOKEN_ERROR, ICE_ERROR, TURN_ERROR. Each has a likely cause and a suggested fix. |
| Chat connections | WebSocket sessions and message counts. Never message content. |
| Audit log | Admin actions. See Audit Logs. |
Some terms in the table: RTT is round-trip time (how long a packet takes to go and come back), jitter is how uneven that delay is, and packet loss is the share of data that never arrived. High values of any of them mean choppy audio or frozen video. More in the Glossary.
A typical investigation
Say alice reports that she couldn't join demo-room this morning.
- Find her connection: list connections in the dashboard, or call
GET /v1/connectionsfrom your backend, and look for her identity. - Open that connection. Its event timeline shows how far she got: token accepted, signaling connected, media connected, or failed.
- If it failed, open the linked error. The category tells you where it
broke. For example,
ICE_ERRORusually means a firewall blocked the connection, andTOKEN_ERRORmeans your backend sent a bad or expired token. - Follow the error's suggested action, or look the category up in Errors.
How connection data gets here
You don't send this data yourself. @livqeno/rtc (in your user's browser)
sends telemetry events to /v1/telemetry/events using the RTC token the
client already has.
Telemetry can never break your call:
- The SDK sends it in the background and never waits for it.
- If sending fails for any reason, the SDK ignores the failure.
- A bad event only fails its own upload. It never touches the call.
What is collected, and how to turn it off: Telemetry & privacy.
Health
/health reports ok only when every service behind it responds. Each check
has a timeout, so a stuck service shows as a fault instead of hanging the
check.
Retention
Connection and error history is not kept forever. The default keeps enough to debug recent incidents. If you need a long-term record, copy what you need into your own storage, for example from webhooks.
Privacy
Message content never appears in these views. livqeno chat conversations
and the dashboard chat views show counts, participants, and times, never
text. The CLI says so in its output.
Not built yet
There are no alerts. Livqeno records the data, but connecting it to
PagerDuty or Slack is up to you. A simple approach: a scheduled job on your
backend calls GET /v1/metrics every few minutes and alerts when the share
of failed connections goes up.
Next steps
- Observability API: the endpoints behind this page.
- RTC troubleshooting: what to do once you know the error category.
- Production checklist: the monitoring items to set up before launch.