Logs and transport messages

FlowPad has three orthogonal log surfaces. Use the right one for the failure you're chasing.

1. Host runtime log (server-side)

Every Host Service runtime writes to <host-home>/logs/runtimes/<runtime-id>.log. For the default install:

/tmp/matrix-home/logs/runtimes/FLOWPAD.log

This captures the runner process's stdout/stderr — basically just the package's console.log output during boot. Because FlowPad has no headless component, the file is sparse: you'll see "FlowPad runtime registered" on start, then nothing unless a build error or process crash occurs.

hivecast status --home /tmp/matrix-home reports the file path and size for each runtime; an unhealthy or restart-looping FLOWPAD runtime will show up there.

2. Browser console (page-side)

The page's index.ts ends with:

console.log('[FlowPad Reengineered] Custom elements registered');

After load you should see that message in DevTools console plus the bootstrap output from FlowpadApp's children:

[Smithers] LLM credentials resolved: ...      ← from sibling packages, not FlowPad
[FlowPad Reengineered] Custom elements registered

Console errors here usually indicate one of:

Missing data-runtime-root on the host element (status pane logs "requested root unavailable").
WebSocket failure to /nats-ws (transport indicator goes red, "Transport: Local (InMemory)" if it falls back).
pnpm workspace symlink mismatch — see Troubleshooting.

3. In-page transport log (the dock tab)

The most useful log for debugging a misbehaving flow is the Transport Log tab in the dock at the bottom of the page. It is rendered by <transport-log> and populated by TransportLog.onAddEntry:

// components/TransportLog.ts:11-22
static accepts = {
  addEntry: { timestamp: 'number', direction: 'string', topic: 'string', payload: 'any' },
  clear: {},
};

The shell subscribes to bus traffic from FlowpadApp's mount and appends every observed envelope. Three colour categories show up:

Direction	Meaning	Colour
`accepts`	Inbox sends targeting an actor's `$inbox`	blue
`emits`	Events emitted via `actor.emit(...)`	green
`lifecycle`	`$lifecycle` (bootstrap, dispose, structure changes)	amber

Click any row to expand the payload preview. Click Clear in the toolbar to wipe.

The log is capped at a fixed length; oldest entries are removed first (entryAdded { entry, removedFirst }).

Reading a misbehaving flow

Click Run
→ accepts: flowpad-page.$inbox / runFromCode { code: '...' }
→ emits:   flowStarted { flowId: 'flow-1714...' }
→ emits:   executionPlanned { flowId, language: 'flow-dsl', irKind: 'query-plan', adapterPath: 'fromValue → ./db.Query' }
→ accepts: flowpad-page.db.$inbox / Query { table: 'products' }
→ emits:   flowCompleted { flowId, result: [...] }

If you see flowStarted but never flowCompleted or flowError, one of the actor mounts is unreachable or timed out. The next step is checking Troubleshooting.

What is NOT in the transport log

HTTP fetches the page makes (e.g., manifest.json for the bundled projects). These appear in DevTools Network panel.
Cross-origin federation requests handled by the runtime adapter (e.g., to https://hivecast.ai).
Deep VLM internals — the VLM debug tab in the dock has its own visualisation; transport-log only sees the outer envelope.

Persisting transport logs

There is no built-in persistence. The transport log is in-memory; reload the page and it's gone. To capture it for a bug report, copy from DevTools console (the underlying envelopes are logged via actorLog per project Rule 9.4) or take screenshots of the dock tab.

Logging level

There is no per-package log-level config in matrix.json. Verbosity is controlled by the MATRIX_LOG_LEVEL env passed to the Host Service supervisor; FlowPad respects it via actorLog() calls in the framework.

Logs and transport messages ​

1. Host runtime log (server-side) ​

2. Browser console (page-side) ​

3. In-page transport log (the dock tab) ​

Reading a misbehaving flow ​

What is NOT in the transport log ​

Persisting transport logs ​

Logging level ​

See also ​