# Logs and timings

> Everything the machine said and everything that took time, in one searchable store — filtered down to what one chat actually did.

Nothing is watching at 3am, so the machine keeps a record.

**logs** is one tile and one screen with two tabs, because it is one store with
two tables in it: **logs**, what the machine said, and **traces**, what took how
long.

## What is in it

The machine's own journal, and every operation that took measurable time. Every
entry carries the machine and — when there is one — the agent and the
chat.

That last part is what makes it worth having. "What did this chat
actually do to the machine" is a filter rather than an afternoon.

## Turning it on

The first time you open **logs**, the panel offers to install the store. It is
one program under `~/.beafk/clickhouse`, and if you say no, nothing else
changes.

It is capped at **ten gigabytes**, and the cap is kept by dropping the oldest
hour — so a machine in a crash loop, which writes a thousand times its usual
volume, cannot fill its own disk.

## Reading the logs

Type a word, choose a window, and narrow by machine, agent or chat.

![the logs screen — an hour of the machine's own record, searchable, with its store size at the foot](https://beafk.app/docs-shots/logs.webp)

Times are **UTC**. A two-hour "lag" between what you remember doing and what the
screen says is almost always your timezone rather than a stalled ingest.

## Reading the traces

The other tab is the answer to *why was that so slow*. Operations are grouped,
longest first, over the window you choose, each carrying the machine and — where
there is one — the agent and the chat. So you get from "something was
slow" to "this chat, this step" without guessing.

What you open it for:

- a chat that felt slow — which part of it actually was;
- a command that used to take ten seconds and now takes four minutes;
- an agent that seems stuck: is it thinking, or waiting on something?
- after a bad afternoon: what was happening at 02:14.

**Two things it usually turns out to be.** The first is the model: most of what
an agent spends is spent waiting for the thing it is talking to, and that draws
as one long span and nothing else. The second is the box. If several long
operations overlap and everything is slow at once, that is
[is the machine all right?](https://beafk.app/docs/is-the-machine-all-right.md) — a machine out of
memory looks exactly like an agent that has become stupid.

## From a terminal

```sh
beafk obs logs -q refused --since 2h    # search what it said
beafk obs traces --since 1h             # what took how long
beafk obs traces --json                 # for something that will read it back
beafk obs status                        # is the store there, and what is in it
```

## Agents read it too

Those are the same lines an agent on the machine uses. beafk hands every agent a
written procedure for this, so "find out why the deploy failed last night" is a
query rather than an archaeology project.

## What is not in it

Your code, and the contents of your chats. This is a record of what the
machine *did* — processes, requests, timings, failures — not a copy of what was
said.

And none of it leaves the machine. beafk cloud has no copy of any of this. What
a machine does send out, when your workspace names somewhere to send it, is a
narrower record — see [telemetry](https://beafk.app/docs/telemetry.md).

---

beafk documentation · Logs and usage · https://beafk.app/docs/logs

In this section:
- Logs and timings — https://beafk.app/docs/logs.md (this page)
- Telemetry — https://beafk.app/docs/telemetry.md
- Usage — https://beafk.app/docs/usage.md
- The trash — https://beafk.app/docs/the-trash.md

Every page, one line each: https://beafk.app/docs/llms.txt
All of it in one file: https://beafk.app/docs/llms-full.txt