Dashboard and Continuous Event Log
Dashboard
For each cycle the portal should show:
- cycle 00 or 12;
- primary/fallback execution source;
- scheduled and actual start;
- completion time and runtime;
- time until the next cycle;
- normalized current state;
- required files available, for example 17/21;
- upload status;
- DNT/XML status;
- response and final Ingested result;
- remote publication verification;
- last event and errors/delays;
- JUNO fallback activity;
- duplicate-risk warning.
Continuous web event log
The portal should also provide a chronological log containing cycle starts/stops, file checks and count changes, upload events and retries, DNT creation/submission, response waiting/receipt, ingestion result, fallback events, remote verification checks and monitoring errors.
The log should be filterable by cycle, source, event type, severity and date.
Portal separation
The portal is based on a lightweight FastAPI/Uvicorn service reading monitoring output. A portal failure must have no effect on production transfers.
Notifications
Notifications are planned for meaningful transitions: start, successful completion, failure, excessive runtime, fallback activation and duplicate-risk detection. Thresholds should be based on observed normal operation and remain separate from production control.