Service monitoring
Monitor the service people actually reach
A monitoring list can fall behind the systems it is meant to cover. PitchAI expanded an existing service monitor into a reconciled inventory, with checks for the page a visitor should reach and the health of the service behind it.
- Context
- Internal operations
- Stage
- Deployed monitoring system
- Published
Start with the live estate
The starting point was a small configured list of services. Other deployed services included public sites, protected applications, aliases and infrastructure endpoints. A repository name alone did not establish whether a service was still live.
We reconciled DNS, proxy routes, deployment records and operational inventories. Active services entered the monitoring configuration. Retired, replaced and non-service names remained separately classified from services expected to be running.
The resulting configuration feeds checks, grouped dashboard views, incidents and rolling history. A change to the inventory therefore reaches both the checks and the views that summarize them.
Check the intended destination
A successful HTTP response does not establish that the intended page appeared. The browser checks can verify the final host, page title, required elements and expected text. Independent API health checks provide another signal.
One protected application exposed a different problem: its sign-in page worked, but the monitor still expected an implementation marker removed by a UI change. The stale check reported a failure even though both the page and its health endpoint responded successfully.
We changed that check to follow the expected sign-in redirect and verify the final host, path and visible sign-in form. The independent health check remained in place. Production verification then showed the corrected check succeeding.
Preserve the evidence behind the status
The monitor uses configurable consecutive-success and consecutive-failure thresholds before changing displayed status. Operators can require repeated observations before a failure or recovery changes that status.
The old false readings were retained in history when the check was corrected. Genuine incidents also stayed visible during the inventory expansion. The dashboard retained the evidence behind its status.
From a list to an operational inventory
The expanded monitor was deployed in August 2026, with fresh production samples and browser verification of its desktop and mobile dashboard.
The original system already ran service checks. The later work connected those checks to a reconciled estate, grouped their results and made a protected sign-in boundary explicit. Operators could see which services were expected to run and what each check had actually observed.