---
title: Troubleshooting
description: A diagnostic order for ClawMetry — empty dashboard, missing runtime, no cost data, stalled sync, store problems, MCP failures and cloud sync issues.
keywords: clawmetry not working, dashboard empty, runtime not detected, clawmetry troubleshooting, no cost data
eyebrow: Operations
---

# Troubleshooting

Work the chain in order. Most problems are one of the first three checks.

## The three commands

```bash
clawmetry status      # is the daemon alive and ingesting?
clawmetry runtimes    # was anything detected?
clawmetry diagnose    # why does it think it is on this tier?
```

## The dashboard is empty

**The daemon is the answer roughly nine times in ten.** The dashboard reads
through it and shows nothing on its own.

```bash
clawmetry status
# daemon: not running  →  clawmetry sync
```

If the daemon is running but pages are still empty:

```bash
DEBUG=1 clawmetry sync --foreground
```

Read what it says. It will tell you which runtimes it found and what it did with
them.

Then check the store has anything at all:

```bash
curl -s localhost:8900/api/local/health | jq
curl -s 'localhost:8900/api/local/sessions?limit=5' | jq '.rows | length'
```

:::note Empty is not an error
Handlers return an empty result with HTTP 200 rather than failing, so a card
renders blank instead of broken. That means **an empty response is not proof of
an empty store** — always confirm with `clawmetry status`.
:::

## A runtime is not detected

Detection is a filesystem check, not a `PATH` check. Almost always the store has
been relocated.

```bash
clawmetry runtimes --json | jq '.runtimes[] | select(.id=="<runtime>")'
```

Then set the override from that runtime's
[reference page](/docs/runtimes/overview/). The ones that catch people most:

| Runtime | The trap |
|---|---|
| Cline | Data is in `~/.cline/**data**`, not `~/.cline` |
| Goose | Uses **XDG paths on macOS**, not `~/Library/Application Support` |
| Gemini CLI | `GEMINI_CLI_HOME` points at the *parent* of `.gemini` |
| Qwen Code | `QWEN_HOME` points *at* the data dir — the opposite of Gemini's |
| Deep Agents | Note the `.state` subdirectory in the default path |
| NanoClaw | No home directory at all — the data dir is relative to the install CWD |
| Aider | Per-project; set `AIDER_HISTORY_DIRS` |
| QM | Needs a Postgres driver: `pip install pg8000` |

## Detected, but no sessions

| Cause | Check |
|---|---|
| Nothing written yet | Run the agent once, then wait a cycle |
| Session limit hiding them | Raise `CLAWMETRY_FAMILY_SESSION_LIMIT` and restart |
| Chat recording off (Qwen Code) | It is opt-in upstream — `--chat-recording` |
| Daemon has not completed a cycle | `clawmetry status` shows last ingest |

```bash
CLAWMETRY_FAMILY_SESSION_LIMIT=500 clawmetry sync --restart
```

Raising the limit alone may not backfill: the daemon tracks a high-water mark
per source, and a cycle that already decided it was caught up will not revisit
that ground. Restart after raising it.

## Sessions appear, but cost is zero or missing

First: **is it genuinely unknown, or genuinely zero?**

```bash
curl -s 'localhost:8900/api/local/sessions?limit=20' \
  | jq '.rows[] | {session_id, cost_usd, cost_status, model}'
```

| `cost_status` | Meaning |
|---|---|
| `unavailable` | The runtime does not persist tokens or dollars. Correct, not a bug. |
| `tokens_only` | Real tokens, no priceable model |
| `estimated` | Derived with a caveat — Kimi resolves its model from current config |
| `exact` | Vendor dollars or fully priceable |

PicoClaw persists no tokens at all. Cursor persists none locally. Those are
`unavailable` by design. → [What each runtime exposes](/docs/runtimes/coverage/)

## Sync is stalled

```bash
clawmetry status --json | jq '{last_sync: .daemon.last_sync, age: .daemon.last_sync_age_secs}'
DEBUG=1 clawmetry sync --foreground
```

Common causes:

- **A very large first pass.** A long history takes a while. `sync-progress`
  shows how far it has got.
- **Memory pressure on the machine.** DuckDB keeps a buffer pool, and a swapping
  machine makes the store look slow when it is fine. Check actual memory
  pressure before tuning anything.
- **A runtime store that is locked or unreadable.** The daemon logs it and moves
  on, so look for the warning rather than a crash.

## The store will not open

```bash
clawmetry verify-integrity --json
curl -s localhost:8900/api/local/health | jq
```

A store reported as invalidated after an abrupt kill usually needs compaction
rather than deletion. Always stop the daemon cleanly — `clawmetry sync
--restart`, not a kill — because a kill mid-write is how this happens.

If it is unrecoverable, the store is rebuildable: delete it and re-sync. You get
back whatever the runtimes still have on disk, bounded by the session limit.

```bash
clawmetry sync --restart          # stop it properly first
cp ~/.clawmetry/local_store.duckdb /tmp/broken-store.duckdb   # keep a copy
rm ~/.clawmetry/local_store.duckdb
clawmetry sync
```

## MCP tools return errors

| Error | Cause |
|---|---|
| "daemon is not running" | It is not, or its discovery file is stale. `clawmetry sync`. |
| Client cannot start the server | `clawmetry` not on the client's `PATH` — use the absolute path |
| Empty results, no error | The window genuinely has nothing. Widen `since`. |

→ [Connect the MCP server](/docs/mcp/install/)

## Cloud sync is not working

```bash
clawmetry status --json | jq '{cloud, endpoint, last_push}'
curl -s localhost:8900/api/cloud-status | jq
curl -s localhost:8900/api/sync-progress | jq
```

| Symptom | Cause |
|---|---|
| "already local-only" on connect | The local marker is set. `--force` overrides it deliberately. |
| TLS failures | A corporate proxy — set `CLAWMETRY_CA_BUNDLE` |
| Connected, nothing appears | The first push of a long history takes time; check `sync-progress` |
| Cloud shows a summary but an empty list | The two-identity mismatch — see [Nodes and fleet](/docs/cloud/nodes/) |

## Something looks locked

```bash
clawmetry diagnose --json | jq
clawmetry runtimes --why <runtime_id>
clawmetry features --why <feature_id>
```

`diagnose` prints every input the resolver used: the license file, the cached
cloud plan, the enforce variable, and the in-process cache. Usually it is a
license that did not activate, a stale plan cache, or a changed machine
fingerprint.

## A control does nothing

Check what the Guard tab says next to the button. A control that cannot work
says why:

- **OpenClaw pause** is advisory without the proxy running. `clawmetry proxy
  start`.
- **A Cursor editor session** is not a separate process and cannot be signalled.
- **A Windows stop** reaches the whole console, not one process.

→ [Pause, stop, kill](/docs/guard/process-control/)

## `clawmetry update` reports a strange version

If your working directory contains a `dashboard.py` — a ClawMetry checkout — it
shadows the installed package and the version comparison is against the wrong
thing. Run it from anywhere else.

## Still stuck

```bash
clawmetry status --json    > /tmp/cm-status.json
clawmetry runtimes --json  > /tmp/cm-runtimes.json
clawmetry diagnose --json  > /tmp/cm-diagnose.json
DEBUG=1 clawmetry sync --foreground 2>&1 | head -100 > /tmp/cm-sync.log
```

[Open an issue](https://github.com/vivekchand/clawmetry/issues/new) with those.
Check them for secrets first — the sync log can name paths, and status includes
your node id.