Two pages give you the raw operational picture of a Business Unit: Events for what happened, and Schedule for when things run.

The Events page #

Events is the unfiltered stream of everything Nimbus has seen — automation runs and data imports, merged into one list, newest first.

Filtering #

Type — automations, imports, or both.
Status — running, success, failed, stopped, or skipped.
Window — last 24 hours, last 7 days, or all time.
Search — match on automation name or customer key.

Reading an event #

Each row shows the name, status, start time, and duration. Nimbus removes redundant "started" rows once a run has a terminal event, so the list stays clean.

Click a row to open the detail modal:

For an automation, the modal lists every activity — query, import, file transfer — with its own status and duration, so you can pinpoint the slow or failing step. Query activities show their target data extension; import activities show their destination.
For an import, the modal shows total rows, rows succeeded, and rows with errors.

Live updates #

The Events page subscribes to a live stream. Automations that start, finish, or fail appear without a refresh. The Home and tenant overview dashboards use the same stream for their live counters.

The Schedule page #

Schedule answers "when does load land?" It shows a 24-hour heatmap of automation runs — each column is an hour, shaded by how many automations ran in it.

Below the heatmap is the automation list. Expand any automation to see its hourly breakdown — run counts and statuses per hour — which makes it easy to spot:

Clustering — many automations firing in the same hour, competing for resources.
Conflicts — jobs that overlap on the same data extensions (see Data Extensions & Queries).
Quiet windows — good times to schedule new work.

Imports #

Imports are swept on a schedule (every 15 minutes by default) rather than pushed in real time, because SFMC reports import results through a separate API. Each import is matched to its destination data extension so you can see exactly which table received the rows.

From an event to a recovery #

Any failed event can be retried on the spot with a manual rerun, even if no monitoring rule covers it. Recurring failures are a signal to add a rule so recovery happens automatically next time.