Canary at a glance
Canary keeps your project’s dependency picture tied to reality: your source code defines what the project actually depends on, and Canary turns that code-driven view into a live dependency inventory, scheduled health checks, and notifications when something drifts.
The loop: discover → check → notify
Discover
Canary starts with discovery. The documenting-service-dependencies skill reads the repository’s source and turns the real dependency surface into consistent dependency records. That matters because the codebase is the source of truth for what the project depends on, not a stale manual list.
Check
Canary then checks each dependency on a schedule. The core dependency and health-check models keep those checks attached to the right project and dependency, and the jobs loop runs them with the right authentication when a dependency needs more than a simple probe. The result is a current view of reachability and health.
Notify
When a check shows downtime, an elevated error rate, or higher-than-normal cost, Canary notifies the owner. The alert loop turns results into action, so the person responsible sees drift quickly instead of finding out later from the vendor or a customer.
Why Canary exists
Canary is the dependency-side expression of gloria.dev’s intent-versus-implementation model. The intent lives in the code and its declared dependencies; the implementation is what actually runs. Canary keeps comparing those two sides so the gap stays visible.