> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ccs.kaitran.ca/llms.txt
> Use this file to discover all available pages before exploring further.

# Dashboard Logs

> Structured CCS telemetry stream plus upstream CLIProxy error inspection

# Dashboard Logs

CCS includes a dedicated `System -> Logs` workspace for operational visibility.
It is now a dedicated operations surface with a structured telemetry stream and
an upstream-error compatibility tab.

## Access

```bash theme={null}
ccs config
# Open System -> Logs
# Or navigate directly to /logs inside the current dashboard session
```

## Workspace Layout

The route exposes two tabs:

* **Stream** - CCS-owned structured runtime telemetry
* **Upstream errors** - legacy CLIProxy error files for compatibility

### Stream

The main stream view is a log workspace, not a raw file dump:

* `Live activity` header with live/syncing/disconnected status pill
* entry, trace, and error counters
* desktop 3-pane layout: filters, entry list, detail panel
* mobile detail sheet when you select an entry
* request-aware filters for source, level, module, stage, requestId, time
  window, and free-text search
* "hide dashboard internals" filtering for quieter review
* live-tail pause/resume controls with pending-count feedback

### Entry Inspection

Selecting an entry opens a detail panel with:

* **Overview** tab for timestamp, stage, requestId, latency, module, and source
* **Context** tab for structured metadata with redaction-aware reveal controls
* **Raw** tab for copyable JSON
* **Show trace** action when the entry belongs to a correlated request trace

### Upstream Errors

The second tab keeps provider and CLIProxy error files visible without making
them the primary logging model. Use it when you need the old error-log lane or
when only `cliproxy.logging` is enabled.

## Storage Model

### CCS-Owned Structured Logs

Native CCS logs live under:

```text theme={null}
~/.ccs/logs/current.jsonl
~/.ccs/logs/archive/
```

These logs are controlled by the top-level `logging` config block and support:

* minimum log level
* log rotation by size
* archive retention by day count
* context redaction
* a bounded in-memory buffer for dashboard reads

### CLIProxy Runtime Logs

CLIProxy runtime files still live under:

```text theme={null}
~/.ccs/cliproxy/logs/
```

Those files are controlled separately through `cliproxy.logging`.

## Configuration

```yaml theme={null}
logging:
  enabled: true
  level: info
  rotate_mb: 10
  retain_days: 7
  redact: true
  live_buffer_size: 250
```

This is separate from:

```yaml theme={null}
cliproxy:
  logging:
    enabled: false
    request_log: false
```

Use top-level `logging` for CCS-owned runtime events. Use `cliproxy.logging`
only when you need extra CLIProxy runtime files for troubleshooting.

## Operational Notes

* Dashboard `/api/logs` reads are intentionally skipped by request logging so
  the log viewer does not recursively log itself.
* The Home route links here through the logs handoff card once you need
  request-level inspection.
* Remote users can inspect logs only within the dashboard access rules
  currently enforced by dashboard auth and localhost-only fallbacks.
* Redaction is enabled by default so persisted context does not leak obvious
  secrets into the log stream.

## Troubleshooting

### The Logs page looks empty

* Check whether top-level `logging.enabled` is still `true`
* Trigger a fresh CCS action, then refresh the page
* If you only enabled `cliproxy.logging`, look in the **Upstream errors** tab

### I only need verbose CLIProxy request traces

Enable `cliproxy.logging.request_log` instead of raising the global CCS logging
level unless you specifically want broader CCS runtime telemetry.

## Related

* [Dashboard Overview](/features/dashboard/overview)
* [CLIProxy API](/features/proxy/cliproxy-api)
* [Configuration Schema](/reference/config-schema)
* [File Locations](/reference/file-locations)