agentleFS
reatlatreatlat/fullstory-claude-plugin/skills/webhook-health/SKILL.md

webhook-health

Skill36 starsChanged 15 days agoMITView on GitHub

Monitor FullStory webhook delivery — success rates, errors, latency, and webhook-driven integration health. Use when troubleshooting webhook failures, monitoring integration health, or verifying webhook configuration.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals.

    line 28
  2. Distinctive:

    Verify what's configured. Webhooks are typically set up in Fullstory's integration settings or API.

    line 34
  3. Distinctive:

    If the user isn't sure, direct them to: Fullstory → Settings → Integrations → Webhooks

    line 39
  4. Distinctive:

    Check for gaps: are specific hours or days missing?

    line 64
  5. Distinctive:

    Check for duplicate sessions (webhook retry can cause duplicates)

    line 65
  6. Distinctive:

    Test: create a test annotation → did it trigger the webhook?

    line 69
  7. Very specific:

    When jira-bug-reporter creates a ticket, does it arrive?

    line 72
  8. Distinctive:

    Check recent error sessions → were tickets created for P0/P1 issues?

    line 73
  9. Distinctive:

    If webhooks are failing, common causes:

    line 77
  10. Distinctive:

    If all webhooks are failing, don't investigate individual endpoints — check the common infrastructure: network, DNS, auth provider.

    line 121

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Webhook Health

Monitor FullStory webhook delivery — is data flowing to your integrations, are webhooks failing, and are your downstream systems healthy?

When to Use

  • "Are our FullStory webhooks delivering successfully?"
  • "Why didn't sessions show up in our data warehouse?"
  • "Check webhook delivery since the configuration change"
  • "Which webhook endpoints are failing?"
  • "Monitor webhook health for the Slack and Jira integrations"

Mental Model

FullStory can send session data, events, and alerts to external systems via webhooks. If webhooks fail, data stops flowing — your data warehouse misses sessions, your Slack channel stops getting alerts, your Jira integration stops creating tickets.

Webhook monitoring has two sides:

  1. Delivery: Did FullStory successfully deliver the webhook? (HTTP 2xx response)
  2. Processing: Did your downstream system correctly process the payload? (business logic failures)

FullStory can tell you about delivery. Processing failures need to be checked in the downstream system.

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: Check webhook configuration

Verify what's configured. Webhooks are typically set up in Fullstory's integration settings or API. Ask the user:

  • "What webhook endpoints do you have configured?"
  • "What events trigger them? (new session, new event, segment export, etc.)"
  • "When were they last known to be working?"

If the user isn't sure, direct them to: Fullstory → Settings → Integrations → Webhooks

Step 2: Check for delivery failures

Build a metric for webhook-related errors or check session data for failed webhook deliveries:

fullstory:build_metric(
  query="custom events related to webhook failures",
  output_type="single_number"
)

Or check if the data pipeline has gaps:

fullstory:build_metric(query="sessions created", output_type="trend")
fullstory:compute_metric(metric_id)
→ compare to your data warehouse: do the session counts match?

Step 3: Verify integration health

For each downstream integration (Slack, Jira, data warehouse, Snowflake), verify data flow:

Data warehouse (Snowflake, BigQuery, Redshift):

  • Compare session count in Fullstory vs warehouse: do they match for the same time period?
  • Check for gaps: are specific hours or days missing?
  • Check for duplicate sessions (webhook retry can cause duplicates)

Slack/Teams notifications:

  • Did alerts fire for recent frustration signals? (Check discover_groups for current signals, then verify actual alert and delivery logs; discovery alone does not prove an alert fired.)
  • Test: create a test annotation → did it trigger the webhook?

Jira/Linear ticket creation:

  • When jira-bug-reporter creates a ticket, does it arrive?
  • Check recent error sessions → were tickets created for P0/P1 issues?

Step 4: Diagnose failures

If webhooks are failing, common causes:

  • Endpoint changed: URL updated, webhook still pointing to old URL
  • Auth expired: API key or token rotated, webhook auth not updated
  • Rate limiting: Downstream system rate-limiting the webhook receiver
  • Payload changed: Fullstory updated the webhook payload format, downstream parser broke
  • Network: Firewall or VPC change blocking outbound webhook traffic
  • Timeout: Downstream system slow to respond (>10s), Fullstory times out

Step 5: Report

## Webhook Health — Last 7 Days

### Configured Webhooks
- Session export → Snowflake: 🟢 12,400 sessions delivered (0 failures)
- Frustration alerts → Slack: 🟡 8 sent, 2 failed (400 Bad Request — Slack channel archived?)
- Segment export → S3: 🟢 4 exports delivered (0 failures)
- Event stream → Kafka: 🔴 0 delivered since Aug 1 (endpoint unreachable)

### Data Pipeline Verification
- Fullstory sessions (last 7 days): 89,200
- Snowflake sessions (last 7 days): 89,198
- Gap: 2 sessions missing — within normal variance ✅

### Action Required
1. 🔴 Kafka endpoint unreachable since Aug 1 — check firewall/VPC rules
2. 🟡 Slack webhook failing for #product-alerts — channel may have been archived. Test the webhook URL.

Webhook Troubleshooting Checklist

SymptomCheck
Zero deliveriesEndpoint URL correct? DNS resolves? Firewall allows outbound?
Intermittent failuresRate limiting? Timeout? Check downstream system logs.
Payload parsing errorsDid Fullstory change the webhook schema? Check changelog.
DuplicatesRetry logic working as expected? Check idempotency key handling.
Data gap (some hours missing)Was there a Fullstory outage? Check status.fullstory.com.

Guidelines

  • Fullstory MCP doesn't have a native get_webhook_status tool in the GA tool reference. You're inferring webhook health from session data, metrics, and integration verification. Be transparent about this.
  • A data gap between Fullstory and the warehouse doesn't always mean webhook failure — the warehouse might have ingestion lag. Check with the data team before raising alarms.
  • Webhook authentication (API keys, tokens) is managed in Fullstory settings, not through the MCP. Direct the user there for auth configuration changes.
  • If all webhooks are failing, don't investigate individual endpoints — check the common infrastructure: network, DNS, auth provider.
  • For mission-critical webhooks (data warehouse, billing), recommend setting up external monitoring (Datadog, PagerDuty) rather than relying on manual checks.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.