Guides
Practical guides
Monitoring an API provider
Provider monitoring is enabled per provider, not per repository — connecting a repository automatically includes it in monitoring for every provider it depends on. Each provider's monitoring health (Healthy, Degraded, Failing, or Disabled) is visible from your dashboard's Providers page, derived from real check timestamps rather than estimated.
Understanding an affected call site
Each affected call site on a change's detail page shows the file, line, and enclosing function, plus an explanation of exactly why it was classified the way it was — a directly matched operation, a possible match with lower confidence, or a call site sharing a function with a confirmed match. Evidence is always traceable back to a real dependency record, never asserted without it.
Reviewing a migration
Every migration's detail page shows the originating API change, the affected code, a summary of what the patch does, the files changed, and the validation results — AST, typecheck, tests, and rescan — each marked passed only if it actually passed. Use the linked Draft PR to review the diff itself before merging.
Configuring migration policies
From your organization settings, choose how confirmed, risk-scored impacts are handled:
- Require human approval — the default. Every candidate waits for a person to approve it before Shimpilot's migration engine runs.
- Auto-create Draft PR — directly affected, migration-ready candidates are queued automatically.
- Allow low-risk only / Allow high-confidence only — narrower automatic-queuing rules.
- Block automatic migration — every candidate is left for manual review, with no automatic queuing at all.
Handling validation failures
If a generated patch fails typecheck, tests, or the post-patch rescan, Shimpilot blocks the pull request and records the exact reason rather than opening a pull request anyway. Blocked migrations remain visible on your dashboard so you can address them manually.