Real‑Time KPI Dashboard, Priority‑Action Strip & Docker Healthcheck Fix in a Vite‑React / NestJS Monorepo TL;DR: I fixed a flaky Docker healthcheck that was resolving to IPv6, added a new KPI endpoint for condos, and built a “Próxima acción” strip that pulls priority actions from a shared NestJS controller.
The changes tighten our dev‑ops monitoring and give the UI instant, role‑aware insights.
The Problem Our monorepo ( + ) started throwing healthcheck failures in CI: inside the Docker network resolves to (IPv6), but the NestJS API only listens on IPv4 ().
The healthcheck never succeeded, causing the whole stack to be marked unhealthy.
At the same time, product owners asked for two UI features: KPI summary on the condos portal homepage that aggregates income/expense in real time.
Priority‑Action strip (the “Próxima acción” bar) that shows the next recommended task for the logged‑in user across all three portals.
Both required new backend endpoints and front‑end components, but the initial attempts quickly hit dead‑ends.
What I Tried First 1️⃣ Healthcheck Replaced with in .
Added a ‑based healthcheck ().
Both still failed because Docker’s network isolates the API container; points to the container itself, not the API service defined in the same compose file. 2️⃣ KPI Endpoint Added a quick directly in that returned a hard‑coded JSON.
The front‑end component tried to fetch from but received a CORS error because the controller was not exported in . 3️⃣ Priority‑Action Strip Created a dummy that rendered static text.
The API side was missing entirely, so the component had no data source.
All three attempts produced either runtime errors or no data, confirming that we needed a more systematic approach.
The Implementation Below is the exact code that landed in the repo (diff excerpts are included for context). 1️⃣ Docker Healthcheck – use service name, not localhost Why it works: Docker’s internal DNS resolves to the correct container IP (IPv4).
The healthcheck now runs inside the same network, reaching the NestJS server reliably. 2️⃣ KPI Executive Summary – backend Key points Added a single endpoint () that aggregates data on the fly—no extra tables needed.
Kept the calculation pure (no rounding side‑effects) and returned a small payload (< 200 B). 3️⃣ Exporting the KPI endpoint Now the KPI route is reachable from the web app. 4️⃣ Priority‑Action Controller – shared endpoint Why a controller only: The UI needed a quick “next thing” list; persisting a whole table would be overkill.
The controller returns a filtered array based on the user role passed as a query param. 5️⃣ PriorityStrip Component – React (client side)