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: data 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 filter by item type, status, start time, or submitter 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 customize which columns display so the list shows the fields your team triages by.

Two habits matter for the exam. First, the Monitoring hub shows historical and in-progress runs for jobs — items that execute, like pipelines and notebooks. Continuously running items such as Eventstreams are monitored inside their own editors, not primarily here. Second, the hub is where you confirm whether a failure is isolated or systemic: one failed pipeline suggests an item-level problem, while a wall of failures at the same timestamp points at a shared dependency such as a source system, a gateway, or capacity throttling — which you would then confirm in the Capacity Metrics app.

When a question asks for the single place to check the status of last night's scheduled jobs across several workspaces, the answer is the Monitoring hub.

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

Each activity row exposes its input and output payloads as JSON. For a Copy activity, the output includes rows read, rows written, throughput, and duration broken into stages, which is how you distinguish a slow source from a slow destination. The error details on a failed activity tell you whether the failure was in the source connection, the sink, or the activity's own logic — the starting point for every pipeline troubleshooting question.

Remember what a pipeline run status actually means. A run is marked failed when an activity on the executed path fails without a configured recovery path; activities can carry retry settings and timeouts, so a transient source blip may surface as a retried-then-succeeded activity rather than a failed run. After you fix a problem you can rerun the pipeline from the failed activity instead of re-executing everything before it — an important behavior when a long ingestion run fails at the final step.

For scheduled pipelines, the run history also records how the run was triggered, so you can separate scheduled executions from manual test runs when you are working 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 the history breaks the run down by table (query) and activity: 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 message from the mashup engine or the destination write — for example a data type that could not be converted for the output destination, or a source credential that expired.

Dataflow Gen2 runs in phases you should recognize in the history: the queries are evaluated, data may pass through staging, and results are then loaded to the output destination (Lakehouse, Warehouse, or other supported destinations). A refresh can fail in any phase, and the per-activity breakdown tells you which one — evaluation failures point at the query logic or the source, while load failures point at the destination schema or permissions.

For recurring failures, check the refresh schedule settings: like semantic models, dataflows support failure notification options so the owner hears about a broken refresh without watching the hub. On the exam, refresh history is the trigger phrase that points at Dataflow Gen2 (and semantic model) monitoring rather than pipeline run history.

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.

Three layers of diagnostics matter here:

• Cell output — for an interactive notebook run, 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 — the run details expose Spark logs, which you need 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 and nowhere else.

The exam distinction to hold onto: the Monitoring hub tells you a notebook run failed; the Spark UI tells you why it was slow. A question about a notebook that completes but takes hours points you at the Spark UI's stage and task view, while a question about a notebook that errors points first at the cell output and driver log. Resource-level questions — is the capacity itself saturated? — belong to the Capacity Metrics app, not the Spark UI.

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, whether it succeeded, and its type — scheduled or on demand — so you can tell a broken schedule apart from a refresh nobody triggered.

A failed entry carries the error message: typical causes are source credentials that expired, a source table whose schema changed underneath the model, memory limits during processing, or an upstream Lakehouse or Warehouse whose load had not finished when the refresh started. That last case is a classic DP-700 scenario: the fix is orchestration — refresh the model from a pipeline's semantic model refresh activity after the load completes, rather than racing two independent schedules.

In the model's settings you configure the refresh schedule itself — frequency, time slots, time zone — and the failure notification option that emails the owner (and optionally other contacts) when a scheduled refresh fails. That built-in notification is the lightest-weight alerting for models; for anything richer, Activator rules apply (next section).

Also know the distinction between refresh surfaces: the refresh history in settings is the authoritative per-model record, while the Monitoring hub lists semantic model refreshes alongside every other job for cross-item triage. For models in Direct Lake mode, data is read from OneLake Delta tables and a refresh is a cheap reframing operation rather than a full import — so a long-running refresh entry on a Direct Lake model is itself a signal something is misconfigured.

You configure alerts with Activator (formerly Data Activator; the item is also known as a reflex). An Activator rule watches a stream of events or values, evaluates a condition, and fires an action — send an email, post a Teams message, or start a Fabric item such as a pipeline or notebook.

The Real-Time hub is where you find the event sources. Alongside external streaming sources it exposes Fabric events, including job events — the succeeded and failed status changes of pipelines, dataflows, notebooks, and other jobs — and OneLake/workspace events. To alert on any pipeline failure in a workspace, you create a rule on the job events source, filter to the failed status, and set the action. This is the exam's intended answer for proactive failure alerting, as opposed to checking the Monitoring hub after the fact.

Activator rules also attach to data, not just job outcomes: you can set an alert from an Eventstream on the streaming values themselves (a temperature above threshold, an order count dropping to zero), from a KQL queryset on query results, or from a Power BI report visual when a measure crosses a condition. That makes Activator the answer to both flavors of alert question — operational (a job failed) and analytical (the data looks wrong).

Choose the mechanism by scope: semantic model and Dataflow Gen2 refresh-failure emails are built into their settings; everything broader — cross-item, event-driven, condition-on-data, or needing a Teams action or an automated remediation run — is Activator.

This mapping is the core of the topic — DP-700 repeatedly asks where you would look for a given item's health.

Note the pattern: jobs (things that run and finish) live in the Monitoring hub; continuous items (Eventstreams, mirroring) are monitored in their own editors; capacity questions always resolve to the Capacity Metrics app.

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.