PipelineGuard

Data pipelines fail silently. A job reports status: SUCCEEDED with records_processed: 0 — no crash, no alert, just wrong numbers downstream until someone notices three days later. This backend catches that: silent failures, latency drift against a rolling p50/p95 baseline, and consecutive-failure patterns, with real multi-tenancy and RS256 JWT auth.

346 tests FastAPI · async RS256 JWT + RBAC Prometheus metrics Clean architecture, Protocol-based ports

Try the real detection flow

This runs against the actual deployed API — a real pipeline gets registered, a real job execution gets reported, and the real DriftAnalyzer / silent-failure rule decides whether to fire a CRITICAL alert. Nothing here is mocked for the page.

1Seeded demo tenant + a fresh pipeline get created on load.

2Pick what the pipeline reports, then submit it as a real job execution.

3See the real classification and, if it's a silent failure, the real alert it triggers.

Setting up a demo pipeline…

Architecture

HTTP Client
    |
    v
FastAPI Presentation Layer     RS256 JWT + RBAC middleware, tenant_id injected per request
    |
    v
Application Services           PipelineService, AuthService, BillingService, GDPRService
    |
    v
Domain Layer                   Pipeline, JobExecution, LatencyRecord, PipelineAlert
    |                           DriftAnalyzer -- rolling p50/p95 + z-score anomaly detection
    |                           AlertDeduplicator -- cooldown-window suppression
    v
Infrastructure Layer            JWT (RS256), RBAC, SQLAlchemy + Alembic, Redis, Celery
    v
Storage: PostgreSQL + Redis    Observability: Prometheus

What's real in this deploy

This demo runs with in-memory repositories (the app's own documented demo mode — src/infrastructure/database/pipeline_repositories.py has the real SQLAlchemy/Postgres implementations for production use). Every request above hits the real FastAPI routes, the real domain logic, and the real in-process alert pipeline — the only difference from a production deploy is what the data is persisted to, and that it resets on a cold start. Slack/webhook alert delivery exists in the codebase but isn't wired to this deploy.