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.
In this repository45 other files it gives its agents.
- a11y-analyzerSkill
- annotation-opsSkill
- anomaly-detectorSkill
- api-monitorSkill
- benchmark-analyzerSkill
- campaign-trackerSkill
- changelog-detectiveSkill
- cohort-compassSkill
- comparisonsSkill
- customer-360Skill
- dashboard-builderSkill
- deploy-radarSkill
- error-forensicsSkill
- experiment-analyzerSkill
- feature-adoptionSkill
- form-analyzerSkill
- frustration-hunterSkill
- funnel-doctorSkill
- general-analysisSkill
- heatmap-generatorSkill
- incident-responderSkill
- jira-bug-reporterSkill
- journey-builderSkill
- lifecycle-analyzerSkill
- metric-auditorSkill
- mobile-analyzerSkill
- nps-proxySkill
- onboarding-tutorSkill
- page-performanceSkill
- persona-builderSkill
- predictive-alertsSkill
- privacy-auditorSkill
- query-translatorSkill
- quick-statsSkill
- report-deckSkill
- retention-analyzerSkill
- revenue-impactSkill
- scroll-depth-analyzerSkill
- segment-wizardSkill
- session-playlistSkill
- session-reviewSkill
- session-searchSkill
- slack-reporterSkill
- user-journeySkill
- weekly-digestSkill
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
- Very specific: line 28
Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals.
- Distinctive: line 34
Verify what's configured. Webhooks are typically set up in Fullstory's integration settings or API.
- Distinctive: line 39
If the user isn't sure, direct them to: Fullstory → Settings → Integrations → Webhooks
- Distinctive: line 64
Check for gaps: are specific hours or days missing?
- Distinctive: line 65
Check for duplicate sessions (webhook retry can cause duplicates)
- Distinctive: line 69
Test: create a test annotation → did it trigger the webhook?
- Very specific: line 72
When jira-bug-reporter creates a ticket, does it arrive?
- Distinctive: line 73
Check recent error sessions → were tickets created for P0/P1 issues?
- Distinctive: line 77
If webhooks are failing, common causes:
- Distinctive: line 121
If all webhooks are failing, don't investigate individual endpoints — check the common infrastructure: network, DNS, auth provider.
≈ “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.
Files
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:
- Delivery: Did FullStory successfully deliver the webhook? (HTTP 2xx response)
- 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_groupsfor 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-reportercreates 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
| Symptom | Check |
| Zero deliveries | Endpoint URL correct? DNS resolves? Firewall allows outbound? |
| Intermittent failures | Rate limiting? Timeout? Check downstream system logs. |
| Payload parsing errors | Did Fullstory change the webhook schema? Check changelog. |
| Duplicates | Retry 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_statustool 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.
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
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.

