[compliance] Compliance Gap: Health Monitoring - Server Status Always Reports "running" with Zero Uptime

[github-actions]

MCP Gateway Compliance Review - 2026-03-31

Summary

Found 1 compliance issue during daily review of commit 3b4c53f (fix: lower repo-assist min-integrity to unapproved).

Note: Previously tracked issue spec-version-constant (MCPGatewaySpecVersion was 1.8.0) has been resolved — the constant now correctly reports 1.9.0.

Recent Changes Reviewed

• Commit 3b4c53f: fix: lower repo-assist min-integrity to unapproved — workflow configuration change only, no impact on gateway core compliance.
• All other specification sections remain compliant (see Compliance Status table below).

---

Important Issues (Persistent SHOULD Violation)

1. GetServerStatus() Always Reports "running" with Zero Uptime

Specification Section: Section 8 — Health Monitoring
Deep Link: https://github.com/github/gh-aw/blob/main/docs/src/content/docs/reference/mcp-gateway.md#8-health-monitoring

Requirement:

Health check includes server uptime and status
Periodic health checks (every 30 seconds recommended)
Automatic restart of failed stdio servers

Current State:

internal/server/unified.go lines 584–604 — GetServerStatus() hardcodes every configured server as "running" and always returns Uptime: 0, regardless of actual connection state:

status[serverID] = ServerStatus{
    Status: "running",
    Uptime: 0, // Will be properly tracked when servers are actually launched
}

The TODO comment ("Will be properly tracked when servers are actually launched") confirms this is a known stub.

Gap:

1. Inaccurate status: The /health endpoint always reports all servers as "running", even if they have crashed, never been contacted, or encountered errors. The BuildHealthResponse() logic only transitions to "unhealthy" when status.Status == "error", which can never happen with the current stub.
2. Zero uptime: Uptime is always 0 — server start times are never tracked.
3. No periodic health checks: There is no background goroutine performing periodic health checks (only a connection pool cleanup ticker exists in internal/launcher/connection_pool.go:101).
4. No automatic restart: Failed stdio servers are not automatically restarted.

Severity: Important (SHOULD violation — spec recommends proactive health tracking and restarts)

File References:

• internal/server/unified.go:584–604 — GetServerStatus() stub
• internal/server/health.go:30–36 — Health logic that relies on accurate status
• internal/launcher/launcher.go:206–252 — Server launch logic with no state tracking

Suggested Fix:

1. Track server connection state in the launcher — Record whether each server has been successfully launched, its start time, and whether its connection has errored:

   type ServerState struct {
       Status    string    // "running" | "stopped" | "error"
       StartedAt time.Time
   }

2. Return actual status — In GetServerStatus(), query the launcher for real connection state instead of hardcoding "running".

3. Track uptime — Store the time.Now() when a server is successfully launched; return int(time.Since(startedAt).Seconds()) for uptime.

4. Optional (SHOULD): Add a background health-check goroutine that pings each backend every 30 seconds and updates server state accordingly.

---

Compliance Status

Section	Status	Notes
✅ Configuration Format (§4.1)	Compliant	mcpServers, all fields, error messages with JSONPath
✅ Variable Expansion (§4.2)	Compliant	\$\{VAR_NAME} with fail-fast on undefined
✅ Containerization (§3.2.1)	Compliant	Docker enforced, direct commands blocked
✅ Protocol Behavior (§5)	Compliant	POST /mcp/{server}, GET /health, POST /close, JSON-RPC 2.0
✅ Server Isolation (§6)	Compliant	Per-session containers, isolated streams
✅ Authentication (§7)	Compliant	API key validation, health exemption, key masking in logs
⚠️ Health Monitoring (§8)	Issue	Status always "running", uptime always 0, no periodic checks
✅ Error Handling (§9)	Compliant	Exit code 1 on startup failure, standard JSON-RPC error codes
✅ Spec Version	Compliant	MCPGatewaySpecVersion = "1.9.0"

Resolved Since Last Review

• ✅ spec-version-constant: MCPGatewaySpecVersion updated from 1.8.0 → 1.9.0

References

• MCP Gateway Specification
• Commits reviewed: 3b4c53f
• Previous review: 2026-03-30

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

• get_file_contents get_file_contents: has lower integrity than agent requires. The agent cannot read data with integrity below "unapproved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Daily Compliance Checker · ◷

[github-actions]

🤖 This is an automated response from Repo Assist.

I've verified this issue against the code. The compliance report is accurate.

What I found in internal/server/unified.go (lines 584–604):

GetServerStatus() hardcodes every server as "running" with Uptime: 0, regardless of actual connection state. The comment in the code itself confirms this is a known stub: "Will be properly tracked when servers are actually launched".

Root cause: The Launcher struct holds connections map[string]*mcp.Connection and a session pool, but there's no StartedAt timestamp or error state stored per server. GetServerStatus() only calls us.launcher.ServerIDs() to enumerate servers and then assumes all are running.

Suggested implementation path (minimal, incremental):

1. Track start time in Launcher — add a serverStartedAt map[string]time.Time field to Launcher and populate it in launchServer() when a connection is successfully established.

2. Track error state — add a serverErrors map[string]error field and set it when a launch attempt fails.

3. Update GetServerStatus() — query these maps instead of hardcoding. A server that has never been launched can return "unknown" or "stopped"; one that errored returns "error"; one with a valid start time returns "running" with real uptime.

This gives accurate status and uptime with minimal scope — no background goroutine needed for an initial fix. The periodic health-check goroutine (SHOULD requirement) can be a follow-up.

Happy to submit a PR for step 1 if it would be useful.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: This may be caused by a repository ruleset violation. See granting bypass permissions for the agent, or please contact support if the issue persists. (Request id: DBBD:280703:11D22A9:18C37EF:69CC0C23)