Monitor Fabric Items: Monitoring Hub, Refresh History, and Activator Alerts

The Monitoring hub is Fabric's central run-history view. Open it from the navigation pane (Monitor) and you see recent activities across the workspaces you can access: pipeline runs, Dataflow Gen2 refreshes, notebook runs, Spark job definition runs, and semantic model refreshes, each with its status (succeeded, failed, in progress, cancelled), start time, duration, submitter, and location.

The hub is a triage surface, not a deep-diagnostic one. Its job is to answer what ran, when, and did it succeed. You stack filters (item type, status, start time, submitter, workspace) to isolate the runs you care about, then select a run to open the item's own detail view where the real diagnostics live. You can also choose which columns display.

Three habits matter. First, the hub shows job runs: items that start and finish. Continuously running items such as Eventstreams are monitored inside their own editors. Second, it does not analyse capacity consumption, and you cannot edit items from it. Third, it is where you tell an isolated failure from a systemic one: one failed pipeline suggests an item-level problem, while many failures at the same timestamp point at a shared dependency such as a source system, a gateway, or capacity throttling, which you then confirm in the Capacity Metrics app.

Naming note: Microsoft is rolling out a new Monitor hub experience (in preview) that reorganises monitoring into pages such as job runs, alerts and capacity. The run-level behaviour described in this lesson is the same in both; expect either name in documentation and questions.

You monitor pipeline ingestion in the pipeline's run details, reading status one level deeper than the run itself: per activity. Open a run from the Monitoring hub or from the pipeline's own run history and you get each activity's status, duration and, for failures, an error code and message.

Each activity row exposes its input and output as JSON, and they answer different questions:

Copy activity details (select the Copy activity in the run to open its performance details: the duration breakdown and advanced metrics) show rows read versus rows written, throughput, and a duration breakdown by stage, which is how you tell a slow source from a slow destination. This is run telemetry from the copy itself; a Delta table's history (DESCRIBE HISTORY) only records the write operations and versions on the destination table, not what was read from the source, the throughput, or where the time went.

Fault tolerance changes how a run reads. With the Copy activity set to skip incompatible rows, rows that cannot be written are skipped and the activity still succeeds, so a succeeded run with rows read greater than rows written means rows were dropped. The skipped rows themselves are recorded only if logging is enabled on the activity, in which case they are written to log files in the configured storage location.

Activities can also carry retry settings and timeouts, so a transient source blip may appear as a retried-then-succeeded activity rather than a failed run.

Beyond a single run's activity list, the pipeline monitoring pages give you three tools: views across runs, the relationship between runs, and rerun options.

Gantt view. The pipeline's run list can switch from a list to a Gantt view, which draws each run as a bar on a timeline grouped by pipeline. Use it to spot runs that overlap (a schedule firing before the previous run finished) and runs whose duration is creeping up. For timing inside one run, use the activity's own duration breakdown instead.

Upstream run and Downstream runs. When one pipeline invokes another, the Monitoring hub's Upstream run and Downstream runs columns show which run triggered which. That is the job hierarchy at execution time. It is different from lineage, which shows how items depend on each other (which item feeds which), not which run started which.

Dependency paths decide the run status. Each activity can connect to the next on four conditions:

A run is marked failed when an activity on the executed path fails and nothing handles it. The trap is the try-catch pattern: if a failing activity has only an On fail path and the activity on that path succeeds (for example a logging or email step), the failure counts as handled and the run is marked Succeeded. Anything watching run-level status, such as an Activator rule on failed Job events, then never fires. Ending the failure path with a Fail activity (custom error message and code) restores a failed run status. Also note that an On completion path runs after successes too, so an alert placed there sends on every run.

Rerun options. From a run's details you can rerun in three ways:

• Rerun the entire pipeline: every activity runs again.
• Rerun from the failed activity: completed activities before it are not repeated, which matters when a long ingestion fails at the last step and the failed step itself was the problem.
• Rerun from a selected activity: start from an earlier activity you choose, needed when an earlier step succeeded but produced bad data that caused the later failure.

For scheduled pipelines, the run history also records how each run was triggered, so you can separate scheduled executions from manual runs when you work out why a load ran twice or not at all.

You monitor a Dataflow Gen2 through its refresh history, reached from the dataflow's options in the workspace or from the Monitoring hub. Each refresh entry shows the start time, duration, status, and whether it was scheduled or requested on demand.

Drill into a single refresh and it is broken down into Tables and Activities: each query that loads data reports its own status, so when a dataflow with a dozen queries fails you can see exactly which table's evaluation or load failed while the others succeeded. The failure entry carries the error from the mashup engine or the destination write, for example a data type that could not be converted for the output destination, or an expired source credential.

A refresh runs in phases you should recognise: the queries are evaluated, data may pass through staging, and results are then loaded to the output destination. The failing activity tells you the phase: evaluation failures point at the query logic or the source, while a run where staging succeeded and the load failed points at the destination schema, mapping or permissions.

Three further details:

• Workspace Status column. The dataflow's status in the workspace list reflects both the last refresh and the last save and validation. A warning there can come from publishing the dataflow, not only from a refresh.
• Detailed logs. Each run's detailed (mashup engine) logs can be downloaded for up to 28 days by anyone with at least the Viewer role.
• Gateway refreshes. For a refresh that ran through an on-premises data gateway, the detailed logs cannot be downloaded at all until a gateway admin enables admin consent for gateway diagnostics on that gateway. If the download is unavailable for a gateway refresh, that consent is the missing step, not your role.

Like other schedulable items, a dataflow's schedule can send failure notifications (see the alert mechanism section). On the exam, refresh history is the phrase that points at Dataflow Gen2 or semantic model monitoring rather than pipeline run details.

You monitor Spark workloads, notebooks and Spark job definitions, through their run details, which open from the Monitoring hub or from the item's recent runs. The detail view shows the Spark application's status, its duration, the snapshot of the notebook as it ran, and access to logs and resource usage.

The snapshot matters whenever the notebook has been edited since the run: the current notebook shows today's code, while the snapshot shows the code, parameters and cell outputs of the run you are investigating. For a failed scheduled or pipeline-triggered run, start there.

Three layers of diagnostics matter:

• Cell output: the failing cell shows the Python, Scala, or SQL exception directly. This is where you catch syntax errors, missing tables, and schema mismatches fastest.
• Driver and executor logs: needed when the failure is not a clean exception: jobs that hang, sessions that die, or executors that are lost mid-stage.
• The Spark UI: the standard Spark web interface, available for running and completed applications. Use it to inspect jobs, stages, and tasks: skewed tasks that run far longer than their siblings, excessive shuffle, and stages that retry all show up here.

The distinction to hold onto: the Monitoring hub tells you a notebook run failed; the snapshot and logs tell you why it errored; the Spark UI tells you why it was slow. Run-level and capacity-level views cannot see executors. Whether the capacity itself is saturated is a Capacity Metrics app question.

You monitor semantic model refreshes in the model's refresh history, opened from the semantic model's settings. Each entry records when the refresh ran, how long it took, its status, and its type, which records how the refresh started: for example Scheduled, On demand (someone selected Refresh now) or Via API (a REST call, such as one from Power Automate or a script).

Read an entry correctly:

• Retries stay inside one entry. If a scheduled refresh fails and is retried automatically, the attempts appear within the same entry, so extra rows mean extra triggers, not retries.
• Data and Query Cache operations. An entry can contain a Data operation (loading data into the model) followed by a Query Cache operation (refreshing query caches and dashboard tiles). They run in sequence and are independent: if the Data operation succeeded, the data loaded, even when the Query Cache step after it failed.
• Completed with warnings. The refresh succeeded and the data is fresh, but a non-fatal problem was found, such as a DAX expression referring to a column that no longer exists. Worth fixing, but not a failed load.
• XMLA endpoint refreshes appear only when they complete all their stages, so the absence of an entry does not prove that an XMLA refresh never ran.

A failed entry carries the error message: expired source credentials, a source schema change, memory limits during processing, or an upstream Lakehouse or Warehouse load that had not finished when the refresh started. That last case is fixed by orchestration: refresh the model from a pipeline's semantic model refresh activity after the load completes, rather than racing two schedules. For Direct Lake models, a refresh is a cheap reframing operation over OneLake Delta tables, so a long-running Direct Lake refresh is itself a warning sign.

Refresh failure notifications are set in the model's scheduled refresh settings: the owner is emailed by default, and you can add other contacts, which must be accounts in the organisation's Microsoft Entra tenant. They cover scheduled refreshes only; on-demand and API-triggered (programmatic) refreshes send no email. Two schedule behaviours look alike but are not:

The model's refresh history is the authoritative per-model record; the Monitoring hub lists the same refreshes alongside every other job for cross-item triage.

You monitor streaming ingestion inside the items themselves, because they run continuously and never appear as finished runs in the Monitoring hub.

In an Eventstream, select a source, operator or destination node and use data preview (sample events), data insights (metrics over time) and runtime logs (warning and error entries with detail). The data insights metrics split into two groups that point at different problems:

A schema mismatch between the stream and a destination table typically shows as data conversion errors on the destination node.

For an Eventhouse (KQL database), check ingestion health on the system overview and with KQL management commands such as .show ingestion failures. Mirrored databases have their own replication monitoring view showing status and rows replicated per table.

The Microsoft Fabric Capacity Metrics app answers capacity-wide questions: which items and operations consume capacity units (CUs), and whether the capacity is being throttled. It does not show run errors, outputs or lineage.

Smoothing spreads each operation's cost over future time so short spikes do not immediately throttle the capacity. Interactive operations (such as report queries) are smoothed over a short window (at least 5 minutes, up to 64 minutes); background operations (pipelines, refreshes, notebooks, Spark jobs) are smoothed over 24 hours. Because of this, throttling usually comes from sustained overuse rather than one spike: background usage keeps counting against the next day.

When smoothed usage exceeds the capacity, the overage is carried forward and Fabric throttles in stages based on how much future capacity has already been consumed:

Background jobs are the last to be refused. Reading the app: the utilization charts plot smoothed usage, while an operation's raw cost appears as its total CU seconds in the timepoint detail. Throttling is shown as delay and rejection percentages over time, not as a list of individual rejected requests.

Workspace monitoring gives a workspace a KQL-queryable log store: once collection is turned on, supported items stream their logs and metrics into a read-only KQL database in a monitoring Eventhouse. In the current experience you manage it through a Monitoring item, which can send data to its own Eventhouse or to the Eventhouse of another Monitoring item, so several workspaces in the same Azure region can be centralised in one place (the older model, a Log workspace activity setting that creates the Eventhouse directly in the workspace, works the same way for querying). You query it with KQL for history and trends the Monitoring hub list does not give you, and you can build alerts on it.

Examples of its tables for this topic:

• ItemJobEventLogs: item-level job events (a pipeline, notebook or dataflow job starting, succeeding or failing).
• FabricDataPipelinesActivityRunsLogs: activity-level pipeline runs, including each activity's duration.

Know its limits:

• The database is read-only; you cannot write your own tables into it.
• There is no backfill: data is collected only from the moment monitoring is enabled.
• Data is kept for 30 days by default; keep more by changing the retention in the database's data policies.
• Querying it needs at least the Contributor role on the workspace.
• The pipeline logs record run outcomes and timings, not the error details of a failed activity.

For workspace-wide alerting, write a KQL query in a KQL queryset over these tables (for example, failed jobs in the last few minutes) and set an Activator alert on it.

You configure data- and event-driven alerts with Activator (formerly Data Activator). An Activator rule watches events or values, evaluates detection settings, and fires an action: send an email, post a Teams message, run a Fabric item (such as a pipeline or notebook), or start a Power Automate flow through a custom action. It is no-code: you build rules in the Activator item or start from Set alert on a source, which can be an Eventstream, a KQL queryset result, a Real-Time hub event, or a visual in a Power BI report. That last source covers the analytical side: Job events tell you a job failed, while an alert on a report visual or a query result tells you the data looks wrong even though every job succeeded.

The Real-Time hub is the tenant-wide catalog of data streams and events, with Set alert built in. Its Fabric event families are easy to confuse:

Job events carry the run-level status of the item, not the error message of an individual activity inside a pipeline.

Detection settings have three parts that work together:

• Summarization (optional): an operation such as Average, Minimum, Maximum, Sum or Total over a time window and step, which smooths the raw signal. An average absorbs brief spikes; a maximum keeps them.
• Condition: a state condition tests every value (Is greater than, Is less than, Is equal to); a change condition reacts only to a transition (Increases above, Decreases below, Changes). A heartbeat condition watches for presence: No presence of data fires when an object stops sending events for a period (data stopped arriving), and Object first appearance fires when a new object shows up.
• Occurrence: Every time the condition is met, when it has been true a number of times, or When it has been true for a duration. Use a duration to ignore conditions that clear quickly.

When rules evaluate. Rules on eventstream data evaluate events as they arrive. Rules created from a KQL queryset or a Real-Time Dashboard run their query on a schedule (every few minutes by default), so they alert on the latest query result rather than on each event.

Pick the mechanism by two questions: which runs must it cover (scheduled only, or also manual and API runs) and what must the alert contain (run status, or an activity's own error).

In the new Monitor hub (preview), an Alerts tab gathers pipeline alerts in one place, where you can turn them on or off and manage schedule failure emails and notifications centrally; the mechanisms themselves are the ones in the table.

Two placement rules follow from the dependency paths. An alert activity belongs on the On fail path of the activity you watch; on On completion it also sends after successes. And if you add such a try-catch branch but still want run-level alerts (Job events, schedule notifications) to fire, end the branch with a Fail activity so the run is still marked failed.

DP-700 repeatedly asks where you would look for a given item's health.

The pattern: jobs live in the Monitoring hub; continuous items are monitored in their own editors; capacity questions resolve to the Capacity Metrics app; custom, queryable history comes from workspace monitoring.

Consider a concrete setup: a pipeline ingests sales files into a Lakehouse at 02:00, a Dataflow Gen2 refresh reshapes them at 03:00, and a semantic model refreshes at 04:00. Business users report stale numbers at 09:00. Walk the monitoring chain the way the exam expects.

Start in the Monitoring hub, filtered to last night's window. You see the pipeline succeeded, the dataflow failed, and the model refresh succeeded — which explains the staleness: the model refreshed over old data because the dataflow between them broke. Open the dataflow's refresh history and drill into the failed run: one table shows a failed load activity with a type-conversion error writing to the Lakehouse destination — the source files added a new column overnight.

The fix has two parts, and DP-700 cares about both. First, resolve the error (adjust the query and destination mapping). Second, fix the process so this cannot be silent again: chain the steps in one pipeline — ingestion, then the dataflow activity, then a semantic model refresh activity — so a failure stops downstream steps instead of letting them run against stale data; then add an Activator rule on Fabric job events filtered to failed status with a Teams action, so the team is notified at 03:05, not at 09:00.

The takeaway shape: Monitoring hub to locate the failure, item-level history to diagnose it, orchestration to contain it, Activator to hear about it.