Acacia EAP · Power BI / Fabric Operations

Daily Data Ops Checklist

Run once each morning · — Progress saves automatically for today only Last run: 2026-10-12 00:06 UTC
0 / 16
Pipeline Monitor Confirmed
Azure Synapse Analytics
Pipelines run in Azure Synapse Analytics (not Fabric). Workspace: aca-synapse-workspace · Resource group: ACA-PBI-RG.  Open pipeline runs monitor →
Cloud Connections Check Confirmed
No on-prem gateway in use
All 6 semantic models share one Personal Cloud Connection (not a gateway) — a known single point of failure, tracked separately as a one-time migration fix rather than a daily item. This panel's daily check is below.
Data Flow Checks Confirmed
Azure Synapse Analytics
This workspace defines no Data Flow activities at all — data-flow list is empty and none of the 3 pipelines contain an ExecuteDataFlow activity. Data movement is done by Copy activities, so the items below are assessed against those. Note: the allowlisted CLI form az synapse activity-run query-by-pipeline-run needs --name, not the documented --pipeline-name flag. 2026-10-12: drilled into the 14:01 UTC Nightly chain: Full Overnight Pipeline (40cde00d, 2 ExecutePipeline wrappers) → Dynamic Pipeline (5f83e76e, 98 activity-run entries returned, zero Failed/InProgress, zero non-empty errorCode values) → nested Static Pipelines (269dece1, 5 named Copy activities). Also sampled the standalone 00:03 UTC hourly Static Pipelines run (cbd0ae80). All Copy activities across every run checked Succeeded, zero error codes. The nightly-vs-hourly Copy duration ratios remain healthy for a third check running: City nightly 140.9s vs. 131.9s hourly (1.07x), ESWQueryActivityEntryTime nightly 140.9s vs. 131.8s hourly (1.07x) — see df-4. Separately, City's row count broke its multi-week exact freeze by exactly +1 row (3,873,931 → 3,873,932) since the 2026-09-28 check — still Fail, see df-3.  Open pipeline runs monitor →
Model Refresh Check Live data
6 semantic models
2026‑10‑12: model list re-confirmed present via Fabric MCP (list_items, all 6 names/IDs match, no drift) across both workspaces. Refresh history pulled live for all 6 models via az rest --method get --url .../refreshes. model-3 shows its latest refresh completing cleanly (2026-10-11 23:15 UTC) after two Resource Governance (out-of-memory) retries earlier in that run. model-4's latest refresh (2026-10-11 23:11 UTC) completed cleanly on the first attempt, with one earlier Resource Governance retry that day (21:10 UTC) that self-recovered. model-1 and model-2 remain stuck on their old "Disabled" schedule, unchanged from prior checks and now well over a year stale in both cases.