SpOps admin — football module
Everything below is read-only: no destructive actions or write endpoints are exposed here, even where the backing infra supports them.
API / DB / storage health
Generated at 2026-09-14 11:52UTC. Redis isn't part of this stack -- nothing here needs a cache (predictions are computed once daily; this page is static JSON) -- so it isn't faked in for the sake of matching a generic tech-stack checklist.
Pipeline runs & schedule
The real Airflow DAG task graph, not a diagram drawn by hand.
Runs in the project's docker-compose Airflow stack; timestamps come from the last successful run.
Production model & registry
- Trained at
- n/a
- Training window
- ? → ?
- Training rows
- 0
How much each base model sways the final call (from the fitted meta-learner, not SHAP).
Precision/recall/F1/ROC-AUC aren't the natural fit here: Layer 1 outputs a 3-outcome probability distribution (win/draw/loss) each match, not a binary label, so this project tracks Brier score and log-loss instead (avg backtest log-loss: 1.341 across 2018/2022 checkpoints — see Backtest on the public site for the full breakdown against baseline).
Training history, tuning, feature importance
No MLflow runs visible right now -- either the tracking server was unreachable at the last export, or none have been logged yet. Empty, not fabricated.
Hyperparameter tuning: scripts/tune_layer1.pyruns a real Optuna search over XGBoost, but honestly does not currently beat the default hyperparameters on the true backtest metric (see PROJECT_BRAIN.md) -- the pipeline runs on defaults, not tuned params. Not hiding that behind a fake "tuned" badge.
Loading live feature importance...
This is a global, XGBoost-only importance (gain-based). For genuine per-match SHAP values, see below.
Real per-match Shapley values from the deployed serving API (POST /explain) — genuine local interpretability (“why did the model say this, for this specific match”), not the global feature importance above. Bars below show each feature's real contribution to the home team's win probability for the matchup selected.
Latency, traffic, containers
Click to take a real latency sample -- no history is persisted server-side yet, so this is a live reading, not a stored time series.
Not yet implementedas persisted metrics -- Render's free tier doesn't expose container-level CPU/memory, and no traffic aggregation is stored yet (Tier 3: Prometheus/Grafana, see CLAUDE.md). What is real today: request-level X-Request-ID/X-Response-Time-Ms headers on every response (see the latency probe), and Docker healthchecks on mlflow/serving/airflow-webserver in the local docker-compose stack, verified live each session (see PROJECT_BRAIN.md).
Missing values, schema, duplicates, drift
7 expected columns checked against the combined historical + live match data.
Zero missing values in the combined match dataset.
Live-ingested 2026 matches already present in the periodically-refreshed historical CSV -- deduplicated by load_combined_matches() before training (see DECISIONS.md: a real double-counting bug this check exists to catch a regression of).
76 duplicate (date, home_team, away_team) key(s) across 49,588combined rows, before the training pipeline's own dedup runs.
Wasserstein distance (normed)· checked daily by the pipeline
History, confidence, bracket evolution
Replaying 73 logged day(s) of real predictions (series: heuristic_l2_montecarlo_v1) -- not the full tournament, since it isn't over yet (final: 2026-07-19).
Metrics, traces, deployments
Live serving metrics
reading /metrics-summary...Serving API unreachable right now (Render free tier spins down after 15 min idle -- the first request cold-starts in ~10s). These are live production counters when it's up, not a static export.
Read client-side from https://wc26-serving.onrender.com/metrics-summary -- a JSON projection of the same Prometheus registry that /metrics exposes. Genuine round-trip numbers, not a fabricated dashboard.
Metrics pipeline: OpenTelemetry → Prometheus → Grafana
The serving API is instrumented with OpenTelemetry traces and a Prometheus /metrics endpoint (RED metrics -- request rate, errors, duration -- plus predictions-by-outcome and the loaded model version). A Prometheus container scrapes it every 15s and a provisioned Grafana dashboard renders it. Bring the whole stack up locally with docker compose -f docker-compose.airflow.yml up; Grafana is then at localhost:3001(admin/admin), dashboard “WC26 Serving API”.
Honest scope: the live counters above are real production numbers from the deployed API. The Grafana UI runs in the local/demo docker-compose stack, not on the Render free tier (which won't host a separate Grafana process) -- so it's a screenshot-and-run artifact, not a public hosted panel. Centralized log aggregation and alerting (Alertmanager) remain genuinely out of scope for this project and aren't faked in.