Skip to content
sprigsprigsprig

Monitoring & troubleshooting

Health

Section titled “Health”
  • Operator control: the installer checks the deployed release and its health probe. The control endpoint is internet reachable for the CLI and admin flows, and every operational request requires an Entra token with the required permissions.
  • Gateway liveness/readiness: GET https://gateway.<apps-domain>/healthz/live (process is up; never checks dependencies, so a storage or DAB blip doesn’t restart an otherwise-healthy replica) and /healthz/ready (same signal today; dependency checks such as OIDC discovery and DAB reachability are planned but not wired in yet).
  • Post-change verification: sprig doctor checks infrastructure and platform health against the active context and labels every result by layer. Run it in the same release environment as install or upgrade so it can compare the active, healthy Container App revisions with the configured image digests. It also checks the served wildcard certificate expiry, platform migration stamp, Ops-only report access, and app ownership. It fails if the admin host does not redirect an unauthenticated request to sign-in, or if the gateway data endpoint accepts an unauthenticated request. Optional gateway and domain checks report not checked when those parts are not deployed.

Telemetry

Section titled “Telemetry”

The platform API and gateway both write to Application Insights / OpenTelemetry (requests, failures, dependency calls) backed by one shared Log Analytics workspace. Use KQL there for runtime health, performance, and dependency troubleshooting. MCP clients on the 2026 protocol can send W3C traceparent, tracestate, and baggage values in request _meta. The gateway continues that context through its platform API dependency call, so the MCP operation and platform work appear in one distributed trace.

Product audit is separate from runtime telemetry. Use the admin console’s Audit > Platform and Audit > Data access pages to investigate actors, operations, data access, outcomes, and detected audit gaps. Those pages provide typed filters, detail views, and full-range CSV export. Do not treat Application Insights or Log Analytics runtime events as the product audit record.

Known failure modes

Section titled “Known failure modes”
Symptom Likely cause Fix
Builder gets not onboarded Not a member of sprig-users Ask Ops to run onboard_builder from chat or sprig builders onboard <upn>; both update the same builder group
Publish fails at app creation Entra or metadata propagation lag Retry; the flow is idempotent
Viewer opens app, stuck on sign-in or gets an unexpected 403 Parent-domain OIDC cookie / redirect misconfigured, or the viewer isn’t in app-<name>-viewers yet Confirm auth.apps.<domain> matches the Entra redirect URI; confirm the share was approved and group propagation (a few minutes) has completed
First control operation after idle is slow Platform API scaled to zero Expected on the first request; retry if the client times out
Upgrade fails before Azure is contacted Missing, altered, or untrusted release manifest/bundle Download both files again from the same GitHub release and verify cosign is installed
ACR import returns unauthorized Temporary source credential expired or was disabled Obtain a new time-limited import credential and retry; already imported releases are unaffected
Dedicated registry fails its ownership check Its SKU, access mode, network setting, or ownership tags changed outside the installer Restore the installer-managed Basic registry contract; do not enable admin or anonymous access as a workaround
Share approval succeeds but viewers still blocked Entra group assignment propagation Allow a few minutes; verify membership on the app’s -viewers group directly in Entra
Viewer opens app, sees empty data Viewer’s identity lacks permission at the source (OBO passes their real identity through) Working as designed: grant data access at the source (or via Ops’s expose_entities mapping), not through sprig

When you need to dig

Section titled “When you need to dig”

Start with the admin console’s Audit pages. Filter by the application, source, actor, action, outcome, or data-access fields, then open the matching record for details. If the product audit shows a failed or incomplete operation, use its timestamp and identifiers to correlate the runtime request, failure, and dependency telemetry in Application Insights.

Each published app’s registration and resource carry sprig-owner / sprig-app tags. Use them to identify the application and owner when correlating Azure resources with product audit records.