Skip to content
Mohd Khizer Hayat

← All work

CS-01 · 2025 – 2026

Reporting and pipeline health monitoring

A small backend service that shows, in one place, whether the reporting stack is fresh and whether the pipelines feeding it actually ran.

2 → 1
Health checks to look at
Measured: two separate systems consolidated into one view
How the health view is assembled
  1. Reporting layerDashboard extract freshness
  2. Orchestration platformPipeline run status
  3. Health serviceFastAPI; secrets via managed identity
  4. One health viewIs the data fresh

Two signals that used to live in separate systems, combined by one small service so a stale dashboard and a failed pipeline show up in the same place.

The problem

The analytics team had no single place to see whether the reporting stack was healthy. When a dashboard went stale or a nightly data pipeline failed, a business user usually noticed before the team did, which quietly eroded trust in the numbers. Nothing tied “is the data fresh?” to “did the pipeline that produces it actually run?”

What I built

A small backend service that makes reporting-stack health observable in one place.

  • A Python service built with FastAPI, deployed on a managed cloud application platform.
  • It surfaces reporting-layer health (dashboard extract freshness) and was extended to ingest pipeline run status from the orchestration platform, so one view answers both questions.
  • Credentials are handled through a managed cloud identity and secret store, so nothing sensitive lives in code or config.
  • The deployment pipeline was moved from the original CI system onto a standard CI/CD workflow with pull-request-gated releases.

My role

Owned end to end: design, build, deployment, then the pipeline-status extension and the CI/CD migration. This is the clearest fully-owned piece of software in my portfolio.

Architecture and trade-offs

  • Build vs buy. Off-the-shelf monitoring existed, but none of it correlated BI extract state with orchestration run state in the team’s own terms. A small, purpose-built service won on fit and cost.
  • Security first. Retrieving secrets at runtime through a managed identity, rather than embedding them, was deliberate, so the service could be shared internally without leaking anything.
  • Incremental delivery. Reporting-layer health shipped first, then pipeline status, instead of waiting to build everything.

Impact

  • Failure detection shifted from reactive (a user reports a stale dashboard) to proactive (the team sees it first). Estimated: the qualitative change is real, but I did not capture a measured before-and-after time to detect.
  • Two separate health checks became one surface. Measured: two systems to one.

The hardest part

Wiring the service to the orchestration platform’s API securely. Getting the identity, scopes and runtime secret retrieval right in the cloud environment was the real engineering challenge, more than the application logic.

Skills shown

System design, Python and FastAPI, cloud application hosting, managed identity and secret management, CI/CD, observability design.