> ## Documentation Index > Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt > Use this file to discover all available pages before exploring further. # System Health & Diagnostics > Use Starfire AI health, diagnostics, and observability data during operations. # System health & diagnostics System Health is the Control Center surface for determining whether Starfire and its dependencies are operating normally. The goal is to replace “try changing random settings until it works” with evidence about the affected layer. ## Start with scope Before changing configuration, determine the blast radius. Ask: * one user or many? * one organization or many? * one model or all models? * one provider route or every route? * web app only or Developer Platform too? * one workflow type such as FORGE/research or the whole runtime? * current billing context only or platform-wide billing? Scope narrows the system you need to inspect. ## Platform dependencies Starfire's production architecture includes multiple cooperating systems. The exact infrastructure can evolve, but the health model includes application and dependency layers such as: * web application * API * database * Redis/cache/state services * queues and workers * storage * realtime/streaming * model providers/routes * search/research providers * email delivery * Stripe/billing integration * background indexing/build workers A healthy frontend page does not prove the whole platform is healthy. ## Health checks A health check should answer a specific operational question, such as whether the API can reach a dependency, whether a worker is processing jobs, or whether a provider route is accepting requests. Health status should be interpreted with latency/error trends rather than as a single permanent truth. ## Diagnostics Diagnostics can connect operational identifiers with the system that handled them: * request ID * run/build/research ID * user or organization * model/provider route * billing/subscription reference * artifact/file/indexing state Use those identifiers to follow the actual failing operation instead of relying only on the user's visible symptom. ## Queue and worker health Long-running workloads depend on background execution. If a build or research job is stuck, inspect whether the job was queued, claimed, running, retrying, failed, or waiting on another subsystem. ## Feature flags and configuration A feature being absent for one cohort can be expected rollout behavior rather than an outage. Compare effective feature/config state before escalating. ## Escalate to an incident Create or update an incident when diagnostics show broader service impact or when a critical dependency is degraded for a meaningful user population. Public documentation intentionally describes operational categories rather than publishing private production hosts, credentials, or infrastructure topology. Track platform-impacting degradation through investigation and recovery. Review feature, model, limit, and maintenance settings that can affect behavior.