02 - User Personas (Health Module)

• 1. Primary (machine consumers)
  • 1.1 The Load Balancer
  • 1.2 The Orchestrator / CI Gate
• 2. Secondary (human consumers)
  • 2.1 DevOps / Platform Engineer (primary human)
  • 2.2 Support Engineer
  • 2.3 School Admin (forward-looking, light)
• 3. Non-persona
• 4. Access summary

Who consumes the health surface. The endpoint itself is machine-to-machine; human personas act on its output. Screens referenced are (proposed) unless noted. Source anchors: health.controller.ts:14-37, redis-health.indicator.ts:12-23, storage-health.indicator.ts:16-26, bullmq-health.indicator.ts:19-37.

1. Primary (machine consumers)

1.1 The Load Balancer

• Job: forward traffic only to a healthy instance.
• Consumes: GET /api/v1/health on a fixed interval.
• Contract: 200 = healthy, 503 = drain (health.controller.ts:27-37, Terminus @HealthCheck throws ServiceUnavailableException on any down).
• Needs: no auth (@Public(), health.controller.ts:15), no session, no tenant headers, stable response shape.
• Frustrations avoided: 30 req/min cap is ample for typical 5-30 s probe intervals (rate-limit.constants.ts:4).

1.2 The Orchestrator / CI Gate

• Job: block deploys when dependencies are down; gate rollouts on DB/Redis.
• Consumes: the same endpoint, plus parseable info/error keys to know which dependency failed (health.controller.spec.ts:21-36).

2. Secondary (human consumers)

2.1 DevOps / Platform Engineer (primary human)

• Job: incident triage - "is the API up or is one dependency down?"
• Workflow: curl /api/v1/health → read status; on error, read error.<key>.status === 'down' to name the culprit (e.g. redis), then open the storage/queue/DB consoles.
• Likes: one request answers everything; Redis reports its ping value (redis-health.indicator.ts:16); BullMQ reports pendingJobs per queue (bullmq-health.indicator.ts:30) as a backlog smell.
• Gaps felt: no uptime/version field (can't tell "which build is up" from the payload); no disk/memory indicator despite Terminus support.

2.2 Support Engineer

• Job: first-response triage for tenant reports ("app is down").
• Flow: checks health screen (proposed); if all up, escalates with tenant context; if a dependency is down, routes to the owning team.
• Needs: human-readable screen, not curl - the "App Health" screen in 05/06 (proposed).

2.3 School Admin (forward-looking, light)

• Job: confirm "StudyLyon is having an issue" during an outage rather than fielding parent calls.
• Needs: the same status cards without technical jargon; last-check time; retry button; no ability to change anything - read-only surface, (proposed).

3. Non-persona

• Tenant users (students/parents/teachers): never see this surface; health is an operations concern. Per PRD, native mobile is out of Phase 1 (PRODUCT_REQUIREMENTS_DOCUMENT.md:144).

4. Access summary