Documentation

Cut through noise with effective filtering

The filter system is your most powerful tool for efficient log analysis. Learn when to use each filter mode, combine strategies, and navigate logs quickly.

Overview

Request Logs can contain thousands of entries across production traffic, playground tests, and CI/CD runs. Without effective filtering, you'll waste time scrolling through irrelevant data. Mastering the filter system makes debugging 10x faster.

Available filters

The filters sit above the Request Logs table. They are open when no filter is applied; once filters are set, the panel shows a summary, and Edit reopens it. Filters are chips in three groups. Selecting several chips in one group shows requests that match any of them; chips from different groups are combined. The current filters are kept in the page URL, so Back to request logs from a request detail returns you to the same filtered list.

Source

FilterWhen to useWhat it shows
ProductionDebugging production issues, monitoring healthRequests sent with your API keys (not from the console)
PlaygroundValidating workflow changes in the consoleRequests run from the console playground
CacheChecking cache hit behaviorResponses served from cache
TestReviewing CI/CD runs and integration testsRequests to workflows in test mode, from the API or the playground

Endpoint

FilterWhat it shows
chat/completionOpenAI-compatible chat completion requests
/aiSynchronous /v1/ai requests
/ai/asyncAsynchronous /v1/ai/async requests
Backend pipelineBackend pipeline (event-driven) requests
OtherGuardrails, budgets, and other internal routes

Revision

FilterWhat it shows
LiveRequests that ran the published Live revision
DraftPlayground requests that ran the current draft
HistoricalPlayground requests that ran a previous revision

Production is based on where a request came from, so test-mode requests sent with your API keys appear under both Production and Test.

With no chips selected you see every request in the project. The list has no free-text search, status filter, or date-range filter; it is sorted newest first and paginated, and you check status and time from the table columns.

Decision tree

Are you debugging a production issue?
→ Source: "Production"
 
Are you reviewing test results?
→ Source: "Test" (covers test-mode runs from both the API and the playground)
 
Are you validating a workflow change before publishing?
→ Source: "Playground" + Revision: "Draft"
 
Are you debugging a backend pipeline?
→ Endpoint: "Backend pipeline"
 
Are you monitoring overall health?
→ Start with Source: "Production"

Filtering strategies

Strategy 1: Funnel approach

Start broad, then narrow down:

  1. No filters: Get the big picture
  2. Source: Production: Focus on production traffic
  3. Endpoint: Narrow to the integration path you're investigating (for example /ai/async or Backend pipeline)
  4. Scan the Status and Time columns: Find the failed requests around when the issue occurred
  5. Click to inspect: Drill into specific requests

Strategy 2: Environment isolation

Match your filter to your current task:

Deploying a workflow change:
1. Test the draft in the playground → Source "Playground" + Revision "Draft"
2. Publish, then compare against earlier runs → Revision "Live" vs "Historical"
3. Monitor real traffic → Source "Production"
4. Each phase uses a different filter to avoid cross-contamination

Strategy 3: Comparative analysis

Use filters to compare behavior across environments:

  1. Run the same prompt in the Playground
  2. Find the same prompt under Production
  3. Compare request/response payloads between the two
  4. Differences may explain production-only issues

Identifying requests by seed_batch

Some request types carry a seed_batch prefix that helps categorize them:

PrefixSourceFilter
(none), or an internal prefix such as route: or compat:openai:Production API callsProduction
test_mode:/v1/ai calls to a workflow in test modeProduction and Test
pg:Console playground (production workflow)Playground
pg_test_mode:Console playground (test mode workflow)Playground and Test
callback:Backend callbacks(included in parent request's timeline)
pg_callback:Playground callbacks(included in parent request's timeline)

Tips for efficient navigation

  • Use the refresh button after making API calls to see the latest logs immediately
  • Scan status badges first: Green means OK, red needs attention, amber means failover was needed
  • Check failed models count: A badge like "2 failed" tells you before you even click
  • Look at duration outliers: Requests much slower or faster than average deserve attention
  • Use pagination wisely: The list is newest first, so recent issues are on the first pages; load older pages only when you need them

Next steps