runlot ドキュメント

リクエスト、cron 実行、キューのバッチ、メールごとに 1 件の記録と、それを対象にした Query Builder、保存したクエリ、ログパターン、そして 1 件のリクエストの表示です。

ワーカーの呼び出しは、すべて記録を残します。リクエスト ID、時刻、ハンドラー、メソッド、ホスト、パス、ルート、ステータス、経過時間、デプロイのバージョン、結果です。この記録はワーカーではなく Runlot のフロントが書き込むため、サンプリングされることはなく、リクエストの途中でプロセスが終了した場合にも存在します。使用量のグラフが数えるのと同じ観測なので、リクエスト数について両者の値が食い違うことはありません。

内容が収集されている場合、記録にはその呼び出しのコンソール出力、例外、スパンも含まれます。

結果

結果は、ハンドラーに何が起きたかを Cloudflare Workers と同じ用語で示します。

結果	意味
`ok`	ハンドラーが値を返しました。`500` を返したハンドラーも `ok` です。その場合は `$response.status` で絞り込みます
`exception`	ハンドラーが例外を投げました
`exceededMemory`	このリクエストの処理中に、プロジェクト自身のメモリ上限によってプロセスが強制終了されました
`exceededCpu`, `exceededWallTime`	ランタイムの上限によって終了しました
`canceled`	応答の前にクライアントが切断しました
`internalError`	プロセスがシグナルで終了しました。記録にそのシグナル名が残ります

メモリ不足で強制終了されたプロセスは、処理中のすべてのリクエストを道連れにし、どのリクエストも何も報告できません。Runlot は後からそれらをプロセスの終了記録と照合するため、それぞれに上限とピークを添えた exceededMemory が表示されます。

Query Builder

Observability → Invocations を開くと Query Builder が表示されます。ビュー(calculations、invocations、events、traces)を選び、次にフィルター、検索文字列、計算、グループ化のキーを指定します。同じクエリは JSON でも表せ、CLI で実行できます。

q.json

{
  "timeframe": { "last": "24h" },
  "view": "calculations",
  "filters": [{ "key": "$response.status", "op": "gte", "value": 500 }],
  "calculations": [{ "op": "count" }, { "op": "p99", "key": "$wall_ms" }],
  "groupBy": ["$route"],
  "orderBy": { "calc": 0, "dir": "desc" },
  "limit": 20
}

runlot logs query --file q.json          # a table
runlot logs query --file q.json --json   # the raw result

組み込みのキーは $ で始まります。$request.path、$request.method、$response.status、$route、$wall_ms、$outcome、$event_type、$deployment.version、$level、$message、$source、$request_id、$span.name、$duration_ms、$region、$country などです。ご自身のキーには何も付きません。userId のようにログに出力したオブジェクトのフィールドや、入れ子の場合は order.total のように書きます。
演算子: eq、neq、gt、gte、lt、lte、includes、not_includes、starts_with、regex(RE2)、exists、not_exists。フィルターはすべて AND で結合されます。
計算: count、count_distinct、min、max、sum、avg、stddev、variance、そして p001 から p999 までのパーセンタイル(2 桁はパーセント、3 桁はパーミル)。
上限: フィルター 20 件、計算 10 件、グループ化のキー 5 件、1,000 行、クエリあたり 10 秒。期間はプランの保管期間に収まるよう切り詰められ、切り詰めた場合は結果にそのことが示されます。

SQL はありません。クエリは、Runlot がプロジェクトのフィルターを加えたパラメーター化 SQL にコンパイルされるため、クエリが他のプロジェクトのデータを読むことはありません。

保存したクエリ

Query Builder からクエリを保存すると、URL が付きます。保存したクエリはプロジェクトの全員が見られます。組織のスコープで保存したクエリは、組織のすべてのプロジェクトから見られます。各自がよく使うクエリにスターを付けられます。Free プランではプロジェクトあたり 10 件まで保存でき、Pro プランには上限がありません。

ログパターン

Patterns タブは、数値、ID などの変化するトークンを隠したテンプレートでログ行をまとめ、パターンごとの件数、サンプル行、最初に見られた時刻、期間内の推移を表示します。新しいパターンや大きく増えたパターンは、クエリを書かなくても目立ちます。

1 件のリクエスト

runlot logs request 4bf92f3577b34da6a3ce929d0e0e4736

Request 4bf92f3577b34da6a3ce929d0e0e4736
  POST my-app.me.runlot.app/checkout → 502  1,204 ms  2026-10-23T03:12:40.118Z
  outcome   exceededMemory (recorded as workerExited)
  route /checkout · v42 · fetch
  exit      exceededMemory at 2026-10-23T03:12:41.004Z (code -1, SIGKILL, OOM-killed, peak 271 MiB of 256 MiB)

Logs (3)
  …

Spans (4)
  fetch /checkout        |####################|   1,204 ms
    db.query SELECT …    |  ####              |     212 ms
  …

確定した結果とそれを説明するプロセスの終了、スタック付きのリクエストのログ、スパンのテキストのウォーターフォール、Runlot Errors で発生したイシュー、そして属する cron、キュー、メールの履歴行を表示します。--json は記録全体を出力します。

同じリクエストのダッシュボード上の表示は /o/<org>/p/<project>/observability/requests/<id> にあります。サインイン時のエラーページからは、ここへ直接リンクします。

API から

ここまでの内容はすべて公開 API として、/v1/orgs/{org}/projects/{project}/observability/ の下にあります。query、keys と values(Query Builder が候補として示すファセット)、patterns、requests/{requestId}、saved-queries です。読み取りには viewer 以上のロールが、クエリの保存には member が必要です。API リファレンスをご覧ください。

Invocations とクエリ

結果

Query Builder

保存したクエリ

ログパターン

1 件のリクエスト

API から

このページの目次