[aterga]

Summary

The scheduled Production health workflow has been red on every tick for weeks (every scheduled run reachable through the API, back to at least 2026-09-09, and all of today's across three different main commits). Each run reports the same two checks failed — "Linked Internet Identity instance" and "Internet Identity health" — while every MCP and OAuth check passes. Production is healthy; the probe cannot tell which II to look at.

Left unpinned, the status CLI learns the II to probe from the instances[] list the server advertises at /version. Production's fronting edge forwards only the MCP and OAuth paths and answers /version with a 308 to the landing site, so the probe sees no advertised II, marks the instance check failed, and the II health check then has nothing to assess. monitoring/mcp-status/checks.js already documents this exact case and the remedy ("Pin one with --ii / II_ORIGIN, as the deployed production target does"), and deploy/native/deploy.sh pins the hosted production dashboard to https://id.ai for the same reason. The off-host probe in health.yml never received that pin.

This sets II_ORIGIN in the job environment, with a comment recording why, and passes it as --ii, mirroring how MCP_ORIGIN is supplied. Side effect worth knowing: with the run red on every tick, the Slack alert has been firing continuously, so a real outage would have been indistinguishable from the noise. After this merges, the first cron tick should go green and the alert becomes meaningful again.

Related issues

Follows #194 (which touched this file only to point the Slack alert at the public status page). The /version redirect it works around is the gateway front described in #165.

Changes

• .github/workflows/health.yml: add II_ORIGIN: https://id.ai to the probe job env with a comment explaining the pin; pass --ii "$II_ORIGIN" to the CLI alongside --mcp "$MCP_ORIGIN".

Testing

• Reproduced locally against production with the workflow's exact env: unpinned, the CLI exits 1, overall: "fail", iiOrigins: [], detail "the server advertises no II instances at /version …"
• Pinned via II_ORIGIN=https://id.ai (env, as the job now sets it) and separately via --ii https://id.ai: exit 0, overall: "pass", iiOrigins: ["https://id.ai"], source "explicitly configured"
• II_ORIGIN is read by monitoring/mcp-status/config.js (resolveConfig) and passed through the same allow-list check as --ii; id.ai is in the default allow-list, so no MCP_STATUS_ALLOWED_HOSTS change is needed
• Workflow YAML parses; .github/scripts/scan-internal-identifiers.sh origin/main...HEAD clean
• cargo build --locked --all-targets — n/a, workflow-only change
• cargo test --locked --all-targets — n/a
• cargo fmt --all / cargo clippy --all-targets — n/a
• npm test --prefix monitoring/mcp-status — n/a, dashboard code unchanged

The workflow runs only on main (schedule / manual dispatch), so it cannot be exercised from this PR; a workflow_dispatch run after merge, or simply the next 15-minute tick, is the confirmation.

Checklist

• I have read the Contributing guidelines.
• Docs (README / comments) updated for any user-visible change.
• No secrets, credentials, or internal-only information are included.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw

---

Generated by Claude Code

[Copilot]

Copilot review overview

🟢 Approval recommended

The pin matches existing deployment configuration and the CLI’s validated configuration path.

Review effort: Balanced
Findings: None

What changed in this PR

Pins the production health probe to the correct Internet Identity origin, preventing false failures caused by /version redirects.

Changes:

• Adds II_ORIGIN=https://id.ai.
• Passes the origin through --ii.

File	Description
.github/​workflows/​health.yml	Configures the production II health target.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.