Docs

Documentation

Visualize the complete request lifecycle

The timeline provides a chronological view of every component in an AI request—provider attempts, webhook deliveries, and backend callbacks—helping you understand the full story behind each request.

Overview

The timeline is the centerpiece of the request detail view, providing a visual, chronological representation of the complete request lifecycle. Instead of seeing just the final result, the timeline shows every step—failed provider attempts, the main request, webhook deliveries, and backend callbacks—so you can understand exactly what happened and why.

How the timeline works

Accessing the timeline

  1. Navigate to Request Logs in your project console
  2. Click any row in the logs table
  3. The timeline appears at the top of the detail view
  4. The timeline remains visible even when viewing specific item details

Visual structure

The timeline displays items in chronological order from left to right (or top to bottom on mobile):

  1. Failover attempts (if any) – Amber/yellow badges showing failed provider attempts
  2. Main request – Green (success) or red (error) badge showing the final result
  3. Webhook deliveries (if async) – Gray/blue/green/red badges showing notification delivery
  4. Backend callbacks (if event-driven) – Lightning bolt icons showing callback status

Each item is clickable, expanding to show detailed information about that specific component.

Timeline components

Failover Attempts

Failed provider/model attempts before the successful request. These show when ModelRiver's multi-provider fallback system kicks in.

  • Full documentation →
  • Visual indicator: Amber/yellow status badge with provider icon
  • Shows: Provider name, model name, duration, timestamp, failure reason
  • Click to view: Request body, response body, and error details

Main Request

The successful or final request that returned the response to your application.

  • Full documentation →
  • Visual indicator: Green (success) or red (error) status badge with provider icon
  • Shows: Provider name, model name, duration, token usage, timestamp
  • Click to view: Complete request body, response body, and metadata

Webhook Deliveries

Webhook notifications sent for async requests or event-driven workflows.

  • Full documentation →
  • Visual indicator: Status badges (gray=planned, blue=delivering, green=success, red=error)
  • Shows: Webhook URL, delivery time, duration, HTTP status code
  • Click to view: Webhook payload, response from your endpoint, retry button

Backend Callbacks

Callback responses from your backend for event-driven workflows.

  • Full documentation →
  • Visual indicator: Lightning bolt icon with "Backend Callback" label
  • Shows: Callback status (success/timeout), timestamp, simulated indicator
  • Click to view: Callback payload, callback response

Reading the timeline

Understanding the chronological flow

The timeline tells the complete story of a request. Here's how to read common patterns:

Simple successful request

[Main Request ✓]

A straightforward request that succeeded on the first attempt with no async components.

Request with failover

[Attempt 1 ✗] → [Attempt 2 ✗] → [Main Request ✓]

Two providers failed before the third succeeded. Check the failed attempts to understand why failovers triggered.

Async request with webhook

[Main Request ✓] → [Webhook ✓]

The AI request succeeded and the webhook was delivered to your backend.

Event-driven request

[Main Request ✓] → [Webhook ✓] → [Callback ✓]

Complete event-driven flow: AI generated the response, webhook was delivered, and your backend called back.

Complex failover + async

[Attempt 1 ✗] → [Main Request ✓] → [Webhook ✗] → [Webhook Retry ✓] → [Callback ✓]

Primary provider failed, fallback succeeded, first webhook delivery failed, retry succeeded, and callback completed.

Why the timeline matters

For debugging

The timeline immediately shows where in the request lifecycle a problem occurred—was it the AI provider that failed, or the webhook delivery, or the backend callback?

For performance analysis

Each component's duration is visible, so you can identify which part of the lifecycle is contributing most to total latency.

For reliability monitoring

Failover attempts are only visible in the timeline. Without it, you'd only see the final result and miss the provider instability underneath.

For async workflow visibility

Webhook deliveries and callbacks are separate from the main request. The timeline connects all components into a single, coherent view.

Next steps