Deploy Radar

Post-deploy health check: compare key metrics before and after a deploy to catch regressions, new errors, and conversion changes.

When to Use

• "I just deployed — did anything break?"
• "Check if the 3pm deploy caused any issues"
• "Compare error rates before and after the July 15 deploy"
• "Did the checkout change improve or hurt conversion?"

Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals. Discovery accepts one scope at a time (page_id, domain, app_name, segment_id, or funnel_id); use a segment for device/user filters and the live schema for time ranges. Use computed metrics for exact custom windows.

Workflow

Step 1: Define the deploy window

Get the deploy timestamp from the user. If they say "3pm today" or "just deployed", pin to the nearest hour.

Define two time windows:

• Before: e.g., 24 hours before deploy (or last 7 days if it was a big release)
• After: e.g., from deploy time to now

Ask: "I'll compare the 24 hours before and after the deploy. That OK, or do you want a wider window?"

Step 2: Check errors

Build an error metric and compute it for both windows:

fullstory:build_metric(query="console errors and network failures", output_type="single_number")
fullstory:compute_metric(metric_id, time_range=before_window)
fullstory:compute_metric(metric_id, time_range=after_window)

Also check for new errors that didn't exist before:

fullstory:build_metric(query="console errors", output_type="top_n")
→ compute for after window, compare to before window
→ flag error types that appear only in the after window

Step 3: Check frustrations

Call fullstory:discover_groups for the after window. For each, call fullstory:get_opportunity_stats. Check if any opportunity's rate-of-change vs the before window shows a spike.

Quick sanity check: rage click count before vs after. If it doubled, the deploy introduced friction.

Step 4: Check conversion

Pick 1-2 key funnels (checkout, signup):

fullstory:compute_metric(funnel_metric_id, time_range=before_window)
fullstory:compute_metric(funnel_metric_id, time_range=after_window)

Step 5: Report

## Deploy Health — v2.3.0 (Aug 4 15:00 UTC)

### Errors
- Before: 12 errors (24h window)
- After: 14 errors (+17%) 🟡
- New: TypeError on /checkout (3 occurrences, did not exist before) 🔴

### Frustrations
- Rage clicks: 87 before → 92 after (+6%) 🟢 (within normal variance)
- Dead clicks: stable
- No new opportunity signals detected 🟢

### Conversion
- Checkout completion: 21% before → 20% after (-5%) 🟡
- Signup completion: 64% → 63% (-2%) 🟢

### Verdict: Deploy is mostly clean. The new TypeError on /checkout is worth investigating — 3 users in 24h, looks like a null check regression. Want me to dig into those sessions?

Step 6: Offer investigation

For any red or yellow flags, offer to run the relevant deep-dive skill (error-forensics, funnel-doctor, frustration-hunter).

Guidelines

• The narrower the windows, the noisier the data. For low-traffic pages, use at least 48h windows.
• A small change before/after doesn't always mean the deploy caused it — natural variance exists. Flag it, but don't claim causation without session evidence.
• New errors (zero before, non-zero after) are the strongest signal. Prioritize those.
• If the user has annotation-ops enabled, create an annotation for the deploy so future analyses can reference it.
• Always include absolute numbers, not just percentages. "5% increase" from 1 to 1.05 errors means nothing. "5% increase" from 100 to 105 is noise.