api-monitor

API Monitor

Monitor API calls that affect user experience — which endpoints are slow, which are erroring, and how API failures manifest in the UI.

When to Use

• "Are our API calls causing user-facing slowness?"
• "Which endpoints are returning the most errors?"
• "Did the backend deploy slow down the checkout API?"
• "Show me sessions where /api/orders failed"
• "What's the slowest API call users experience on /dashboard?"
• "Compare API error rates before and after the backend deploy"

Mental Model

Fullstory captures network requests made by the browser — XHR and Fetch calls. You can see which endpoints users hit, how long they took, and which ones failed. This gives you the user's perspective on API performance, which is different from server-side metrics.

A slow API is invisible server-side but very visible to users: spinners, blank pages, rage clicks on submit buttons.

Workflow

Step 1: Identify API-heavy pages

Which pages make the most API calls?

fullstory:build_metric(
  query="sessions with network activity on /dashboard",
  output_type="trend"
)

Or build segments for pages known to be API-heavy: /checkout, /dashboard, /search, /reports.

Step 2: Find API errors from user sessions

fullstory:build_metric(
  query="network errors (4xx or 5xx responses) on /checkout",
  output_type="top_n"
)
→ group by endpoint to see which API is failing

Present: "504 on /api/orders: 156 users affected (85% of all checkout API errors). 429 on /api/search: 42 users (rate limited)."

Step 3: Investigate error sessions

For the worst endpoint:

fullstory:build_segment("users who received 504 from /api/orders in last 7 days")
fullstory:get_sessions(segment_id, limit=5)
→ session-context agent: "What happened after the 504 error? Did the user retry? See an error message? Abandon the page?"

Step 4: Measure API latency impact

Slow APIs (not errors, but >2s response time) cause UX friction:

fullstory:build_metric(
  query="sessions with network request >2000ms on /checkout",
  output_type="single_number"
)