# Monitor Reliability > Proactive reliability health check using auto-captured error and network failure data. Uses mcp__Amplitude__query_amplitude_data, mcp__Amplitude__get_charts, mcp__Amplitude__get_context. - Skill: `kienbui1995/monitor-reliability` (Agent Skill) - Install (CLI): `npx skillmds@latest add kienbui1995/monitor-reliability` - Raw SKILL.md: https://api.skillmd.com/api/skills/kienbui1995/monitor-reliability/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kienbui1995 (https://skillmd.com/u/kienbui1995) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kienbui1995/monitor-reliability --- # Monitor Reliability ## When to Use - Daily or weekly scheduled reliability review (before users notice issues) - Immediately after a production deployment — is anything broken? - When on-call monitoring alerts are quiet but you want to verify application health - Before a major event (product launch, marketing campaign) — ensure system is stable - When a team wants to establish baseline reliability metrics for SLO definition - Complement to infrastructure monitoring (Datadog, CloudWatch) with user-experience data ## Core Jobs ### Phase 1: Establish Baselines Before classifying anything as "abnormal," establish what normal looks like for this product. **Baseline sources:** - Same time window, previous week (7d rolling — controls for day-of-week patterns) - Same time window, previous day (24h rolling — controls for time-of-day patterns) - Use `mcp__Amplitude__get_charts` to find pre-built error rate charts if they exist **Baseline template:** ``` Product: Check period: Baseline period: Normal error rates (established from 30d history): Network error rate: ~0.3% of sessions JS error rate: ~0.1% of sessions Error click rate: ~2.1% of sessions ``` If no prior baseline exists: treat today as Day 1, document these numbers as the starting baseline. ### Phase 2: Check Network Error Rates API failures are the most impactful errors — they block user actions entirely. **Query:** ``` mcp__Amplitude__query_amplitude_data: event: "[Amplitude] Network Error" time_range: last 24h group_by: endpoint, http_status_code metric: unique users affected ``` **What to look for:** - **Rate increase**: Is network error rate up >20% vs. baseline? → Flag as Yellow - **New endpoints**: Any endpoints in top errors that weren't in yesterday's list? → Flag as new regression - **4xx vs. 5xx split**: 4xx errors are often client-side (bad inputs, auth issues); 5xx are server-side failures - **High-volume endpoints**: `/api/auth`, `/api/data/save`, `/api/payments` failing → Critical - **Low-volume endpoints**: admin or rarely-used endpoints failing → Medium priority **Threshold guidance:** ``` GREEN: <0.5% of sessions have network errors, stable vs. baseline YELLOW: 0.5–2% of sessions affected, or >20% increase vs. baseline RED: >2% of sessions affected, or critical endpoint (auth/payment) failing ``` ### Phase 3: Check JS Error Rates Unhandled JavaScript exceptions break page functionality even when APIs are working. **Query:** ``` mcp__Amplitude__query_amplitude_data: event: "[Amplitude] JS Error" time_range: last 24h group_by: error_type, file metric: unique users affected ``` **What to look for:** - **Unhandled promise rejections**: Often indicate async code without error handling - **TypeError / ReferenceError**: Classic signs of code accessing undefined data — common in regressions - **New errors since last deploy**: Errors with `first_seen` after the last deployment time - **Error location**: Errors in critical files (checkout.js, auth.js, payment.js) are higher severity **Threshold guidance:** ``` GREEN: <0.1% of sessions have JS errors YELLOW: 0.1–0.5% of sessions affected, or new error types since last deploy RED: >0.5% of sessions affected, or error in payment/auth critical path ``` ### Phase 4: Check Error Click Rates Error clicks — rage clicks and clicks on broken elements — reveal UX failures that don't generate HTTP errors. **Query:** ``` mcp__Amplitude__query_amplitude_data: event: "[Amplitude] Error Click" time_range: last 24h group_by: element, page_url metric: unique users affected ``` **What to look for:** - **Rage clicks on specific elements**: Buttons that don't respond, forms that don't submit - **High concentration on single page**: Indicates a broken flow rather than scattered UX issues - **Correlation with abandonment**: Pages with high error click rate + high exit rate = broken flow **Threshold guidance:** ``` GREEN: <2% of sessions have error clicks YELLOW: 2–5% of sessions, or concentrated on one key page RED: >5% of sessions, or concentrated on checkout/signup/critical flows ``` ### Phase 5: Compare to Previous Period For each metric, calculate week-over-week and day-over-day change: ``` mcp__Amplitude__query_amplitude_data: same queries as above time_range: previous 24h / previous 7d equivalent ``` **Change threshold rules:** - **>20% increase** in any error type → investigate cause (deploy? config change? traffic spike?) - **New endpoint/error appearing** → investigate as potential regression - **Stable or decreasing** → no action needed **Correlation check:** - Did error rate change correlate with a deploy? (check deploy log times) - Did it correlate with a traffic spike? (check session volume) - Did it correlate with a third-party service incident? ### Phase 6: Surface Top 3 Reliability Risks Aggregate findings into a concise risk summary. Don't list everything — prioritize the top 3 issues that need action. For each risk: 1. **What**: specific error type and affected endpoint/element 2. **Scope**: how many users affected? 3. **Trend**: is it getting worse, stable, or improving? 4. **Recommended action**: specific next step ## MCP Tools - `mcp__Amplitude__query_amplitude_data` — query error event volumes by type (network, JS, error click), compare across time periods, group by endpoint/element - `mcp__Amplitude__get_charts` — retrieve pre-built error rate charts and reliability dashboards; check if baselines have been previously established - `mcp__Amplitude__get_context` — get project context and understand what error events are being captured; verify auto-capture is configured correctly ## Key Concepts - **Auto-captured errors**: Amplitude records network errors, JS errors, and error clicks automatically when session replay is enabled — no custom instrumentation required - **Error rate vs. error count**: Rate (errors / sessions) is more meaningful than count — it controls for traffic volume changes - **Regression signal**: An error metric that increased sharply at a specific timestamp, correlating with a deployment or configuration change - **Reliability scorecard**: A structured summary of error rates by category with GREEN/YELLOW/RED status — enables quick communication to stakeholders - **Baseline drift**: When error rates slowly increase over weeks without triggering acute alerts — requires periodic review to detect ## Output Format ``` ## Reliability Health Check —