Apps4U2 — App Monitoring Azure · Central US · rg: ufotracker-rg

Checking…

—

Live status · polled directly from each app's /health

Platform health · live from /status · shared plan + Postgres

Postgres connections

—

vs B1ms cap

App Service plan CPU

—

shared compute (ufotracker-plan)

Plan memory

—

B2 · 3.5 GB

Shared platform resources

Drill down in Azure · traces, logs & history (require sign-in)

External services

Quick queries · paste into Log Analytics → Logs

Heads-up: the browser couldn't read one or more /health responses. This is almost always CORS (the API only allows its own web origins), not the app being down — verify with curl or the portal. To enable live polling here, add this dashboard's origin to CORS_ORIGINS, or open a public CORS exception for the /health route.

What's live here: up/down, database reachability, auth mode, and latency come from each app's /health (a real SELECT 1, so green = app + DB + pooling all OK). Requests, 5xx, response time, Postgres connections, and plan CPU/memory are real Azure Monitor values served by each app's /status route (the API reads them with its managed identity — Monitoring Reader — so no secrets reach the browser; results cached ~45s). The Drill down tiles launch into Azure for exception traces, log stream, and history. Until the /status route + role are deployed, the 15-min tiles and platform gauges show — with a reason.
Not yet wired: automatic alerting (no action group / metric alerts). Until that exists this page is look-when-you-want — keep a tab open or pair with an external uptime check on the two /health URLs. See AZURE_MONITORING.md §6.