Methodology

1. Provider Selection Criteria

We document errors from 32 AI providers. Not every AI service qualifies — we use these criteria to decide which providers to cover:

Inclusion Criteria (any three of these)

• Developer traction: API has 1,000+ monthly active developers
• Community volume: Active Discord/GitHub/subreddit with regular error discussions
• Documentation exists: Provider maintains public API documentation we can cite
• Stable API surface: Not in closed beta, publicly accessible API
• Distinct error patterns: Provider has provider-specific errors, not just standard HTTP
• Search demand: Provider's errors appear in Google keyword tools with meaningful volume

Provider Tier System

2. Error Discovery Process

We identify errors to document through five parallel channels:

Channel 1 — Our Own Team Encounters

We build AI-integrated projects internally. Every error our team hits becomes a candidate for documentation. This is our most valuable channel — real errors from real production usage.

Channel 2 — Provider Changelogs and Documentation

Every major AI provider publishes changelogs. We monitor:

• Anthropic API changelog and community forum
• OpenAI DevDay announcements and documentation diffs
• Google AI Studio and Vertex AI release notes
• Cursor Discord announcements
• Provider Twitter/X accounts for breaking changes

Channel 3 — Community Signals

Errors that developers are actively hitting appear in:

• r/ClaudeAI, r/OpenAI, r/LocalLLaMA, r/PromptEngineering, r/CursorAI
• Anthropic Discord, OpenAI Discord, Cursor Discord
• GitHub issues on official SDK repositories
• Stack Overflow tags for major providers
• Hacker News threads about outages and API changes

Channel 4 — Reader Submissions

Community members submit errors they've hit via info@aierrorhub.com. Submissions are triaged, tested, and (if valid) documented within 5 business days.

Channel 5 — Automated Monitoring

Our live status monitoring system logs every 5xx response and rate limit event across the 32 providers we cover. When patterns emerge (spike in a specific error code), we prioritize documentation.

3. Taxonomy Design

Every error is classified along three orthogonal axes:

4. Error Categorization System

Our 30 error categories are designed to help developers find fixes even when they don't know which provider they're using. A rate limit is a rate limit whether it comes from Claude or OpenAI — the fix patterns rhyme.

Category Groups

• Access & Auth (5): Rate Limits, Authentication, Quotas & Billing, Region/Availability, Enterprise/Team
• Request Format (6): Context Window, Message Format, Model Deprecation, Tool Use, Structured Output, File API
• Runtime & Response (6): Timeouts, Server 5xx, Streaming, SDK Issues, Content Moderation, Safety/Refusals
• Advanced Features (7): Extended Thinking, Prompt Caching, Batch Processing, Assistants API, Realtime API, Fine-tuning, Embeddings
• Multimodal (4): Vision, Voice/TTS, Video Generation, Image Generation
• Ecosystem (2): MCP Protocol, IDE Integration

Why 30 Categories, Not More?

We tested 50, 40, and 30 category configurations. 30 was the sweet spot — narrow enough that each category has 40-200 errors (enough for a useful hub page), broad enough that developers don't have to guess between overlapping labels.

5. Error Page Template

Every error page follows the same 7-section structure. Consistency helps developers scan quickly:

6. URL Structure and SEO

Every URL follows a predictable pattern designed for both humans and search engines:

URL Design Principles

• Lowercase, hyphenated slugs — no underscores, no camelCase
• Provider slug first — helps humans scan URLs and helps Google understand hierarchy
• Descriptive error slugs — /rate-limit-error/ not /error-429/
• Trailing slash consistency — every URL ends with /
• No query parameters in canonical URLs — filters use hash routing where possible
• Human-readable — you can guess a URL from an error message

7. Custom Data Fields

Beyond visible content, every error page carries 13 structured data fields powering search, filtering, and schema markup:

8. Severity Classification

Every error carries a severity rating that helps developers prioritize:

9. Related Error Linking Algorithm

Every error page links to 5 related errors. These aren't random — they're computed using a similarity algorithm across:

1. Same category, same provider — highest priority (e.g., other Anthropic rate limit errors)
2. Same error code, different providers — cross-provider learning (429 errors across all APIs)
3. Same category, different providers — pattern recognition (all context window errors)
4. Preceding/following in error flow — errors that often occur together
5. User co-visits — errors that visitors to this page also viewed

10. Live Status Monitoring Technical Details

Our status pages at /status/ aggregate real-time health data across 32 providers.

How We Monitor

• Direct API pings: Cron jobs hit each provider's health endpoint every 60 seconds
• Provider status page scraping: We parse official status.provider.com pages every 5 minutes
• Community signal aggregation: We monitor #outage channels on major Discords for early warning
• Timing benchmarks: We measure response latency to detect degradation before full outages

Status Categorization

• Operational (green): Response time within 2x baseline, no error spike
• Degraded (yellow): Response time 2-5x baseline, or error rate above 5%
• Down (red): No successful responses in last 3 minutes, or error rate above 50%

11. Technology Stack

The infrastructure powering AI Error Hub:

Related reading:

• Editorial Standards — How we verify and test content
• About Us — Our team and mission
• Disclaimer — Content accuracy caveats