home / skills / openagentsinc / openagents / worker-logs

worker-logs skill

/.skills/worker-logs

This skill helps you tail and inspect Cloudflare Worker logs from the CLI to debug API 401/500 and inspect headers.

npx playbooks add skill openagentsinc/openagents --skill worker-logs

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.2 KB
---
name: worker-logs
description: Tail and inspect Cloudflare Worker logs from the CLI. Use when debugging API 401/500, openclaw auth, or web app errors. Covers both the homepage worker (apps/web) and the API worker (apps/api).
---

# Check Cloudflare Worker logs

Use this skill when you need to see what is happening inside the deployed Workers: request paths, response status, console.log output, and errors. Both the main site and the API are separate Cloudflare Workers.

## When to use this skill

- Debugging 401/500 from openagents.com or openagents.com/api.
- Verifying that a Worker receives the expected headers (e.g. X-OA-Internal-Key) and why it might return "unauthorized".
- Seeing console.log / console_error! output from the Rust API or the web app.
- Correlating with Convex logs (Convex calls the API worker; tail the API worker while reproducing).

## Workers in this repo

| Worker | Config | Routes | Purpose |
|--------|--------|--------|---------|
| **openagents-api** | `apps/api/wrangler.toml` | `openagents.com/api/*` | Rust API: openclaw, control, D1, R2, etc. |
| **openagents-web-app** | `apps/web/wrangler.jsonc` | `openagents.com` (main site) | TanStack/React app (Node compat). |

Run `wrangler tail` from the **app directory** that contains that worker's config (or use `--config` / `--cwd`).

## Wrangler tail (real-time only)

Cloudflare does **not** provide historical Worker logs via the CLI. You get a **live stream** of requests and logs. For historical data, use the dashboard: Workers & Pages → your worker → Logs / Real-time Logs or Logpush.

### Basic usage

```bash
# API worker (Rust) — run from apps/api
cd apps/api
npx wrangler tail

# Web app worker — run from apps/web
cd apps/web
npx wrangler tail
```

Leave the command running, then reproduce the issue in the browser. You'll see each request, status, and any console output.

### Tail options

| Option | Meaning |
|--------|--------|
| `--format pretty` | Human-readable (default). |
| `--format json` | One JSON object per log line (e.g. pipe to `jq`). |
| `--status ok` | Only successful requests. |
| `--status error` | Only errors/failures. |
| `--method GET` | Filter by HTTP method. |
| `--search "openclaw"` | Filter by text in console.log messages. |
| `--header "x-oa-internal-key"` | Filter by presence of header. |
| `--sampling-rate 1` | Log 100% of requests (default can sample). |

### Examples

```bash
# API worker: only errors, pretty
cd apps/api
npx wrangler tail --status error --format pretty

# API worker: JSON and filter by URL path with jq
cd apps/api
npx wrangler tail --format json | jq 'select(.url | contains("openclaw"))'

# Web worker: tail while reproducing a page error
cd apps/web
npx wrangler tail
```

### Two workers, two terminals

To see both the site and the API when debugging a flow (e.g. Hatchery calling Convex, Convex calling API):

1. Terminal 1: `cd apps/api && npx wrangler tail --format pretty`
2. Terminal 2: `cd apps/web && npx wrangler tail --format pretty`
3. Optional: Convex logs in a third terminal: `cd apps/web && npx convex logs --prod --success`

Then reproduce; watch for the request to the API worker and any `console.log` / diagnostic output.

## Limitations

- **Real-time only:** No `--history`; tail streams until you Ctrl+C.
- **Sampling:** Under heavy load, tail may sample; use `--sampling-rate 1` to reduce sampling.
- **Max 10 clients:** Up to 10 concurrent tail sessions per worker.
- **Secrets:** Logs must not print secrets; use lengths or "present/absent" in diagnostic logs.

## Diagnostic logging (this repo)

For openclaw auth, the API worker logs:

- **`openclaw auth: no internal key header path=...`** — request reached the worker but the `X-OA-Internal-Key` header was missing (e.g. stripped or not sent by Convex).
- **`openclaw auth 401: path=... provided_len=... expected_len=...`** — header was present but value didn’t match the worker secret (compare lengths; if equal, values differ).
- **`openclaw auth ok path=... key_len=...`** — internal key matched; request was authorized.

Use `wrangler tail` from `apps/api` while reproducing 401 to see which line appears. Convex actions log `[openclawApi <label>] fetch key_len=<n> url=...` before each request; correlate with worker logs to confirm what Convex sent vs what the worker received.

Overview

This skill tails and inspects Cloudflare Worker logs from the CLI to help debug the site and API Workers. It focuses on real-time request/response traces, console output, and authentication diagnostics for the homepage worker (apps/web) and the API worker (apps/api). Use it to see why requests return 401/500 and to verify headers, secrets, and runtime errors.

How this skill works

Run wrangler tail from the worker’s app directory (or pass --config/--cwd) to open a live streaming log of requests, statuses, and console output. You can filter the stream (status, method, header, search text, JSON vs pretty) and run separate tails for the web and API workers in parallel. Logs are real-time only; for historical data use the Cloudflare dashboard or Logpush.

When to use it

  • Reproducing 401/500 errors from openagents.com or openagents.com/api.
  • Verifying that X-OA-Internal-Key or other headers arrive intact and why authorization failed.
  • Watching console.log and console_error output from the Rust API or the web app while reproducing an issue.
  • Correlating Convex or other service calls with API worker behavior by tailing both sides simultaneously.
  • Monitoring live traffic during deployments or troubleshooting intermittent failures.

Best practices

  • Run npx wrangler tail from the worker’s app directory (apps/api or apps/web) or pass --config/--cwd to point to the correct wrangler file.
  • Use --format json when piping into tools like jq for reliable filtering and correlation with other logs.
  • Filter aggressively (--status, --method, --search, --header) to reduce noise and avoid sampling on high traffic.
  • Set --sampling-rate 1 to capture 100% of requests if you suspect sampling hides the issue.
  • Do not log secrets directly; log presence/length or masked values for diagnostics.

Example use cases

  • Debug a 401 from the API: cd apps/api && npx wrangler tail --status error while reproducing the failing request to see openclaw auth lines.
  • Trace a page error: cd apps/web && npx wrangler tail and reproduce the UI flow to capture console logs and request statuses.
  • Compare Convex and API activity: Terminal 1 tails apps/api, Terminal 2 tails apps/web, Terminal 3 shows Convex logs; reproduce the flow to follow the request chain.
  • Filter logs for openclaw: npx wrangler tail --format json | jq 'select(.url|contains("openclaw"))' to inspect only relevant API calls.

FAQ

Can I get historical logs from wrangler tail?

No. wrangler tail provides a live stream only. For historical logs use the Cloudflare dashboard (Workers → your worker → Logs / Real-time Logs) or Logpush.

Why do I see fewer entries under heavy load?

Tail may sample under high traffic. Use --sampling-rate 1 to request 100% logging, but be mindful of rate limits and the 10-client concurrent tail limit.