Why this page is text-only
Background work has several authoritative histories rather than one universal screen: import/export runs, Sync Monitor cycles, dataset and model history, subscriptions, Message Log, workflow runs and mobile sync failures. Showing one empty Sync Monitor as the picture for all of them would overstate its scope, so this cross-cutting page deliberately has no screenshot. Follow the table below to the owning history, where a screenshot can be exact to that mechanism and its retry semantics.
A lot of xMatix runs in the background: imports and exports, scheduled sync cycles, dataset refreshes and model builds, subscription deliveries, outbound messages, workflow instances. Each keeps its own history, and every history entry carries a status and an error message — so background failures are diagnosed by reading the right history screen, not by staring at the record that didn't change. This page maps where each kind of work is visible, then gives the reading habits that apply across all of them.
Where each kind of background work is visible
| Work | Where to see it | Guide |
|---|---|---|
| Data imports | Setup → Administration → Data Import → History — every run with status, counts and per-row errors; import jobs also appear under Setup → Administration → Monitoring → Jobs | Import data |
| Data exports | The Data Export history — re-run past exports and download files before they expire | Export data |
| Integration sync runs | Sync Monitor (Setup → Platform Operations → Monitoring → Sync Monitor) for health across profiles; a profile's Cycles tab for its runs; the owning integration app's Errors tab for failed and dead-lettered runs | Sync health, conflicts and failed runs |
| Dataset refreshes, model builds, archive runs | The per-object history: the dataset's Refresh History tab, the model's Build History tab, the archive rule's History action | Refresh scheduling and monitoring |
| Subscription deliveries | The report library's Subscribed scope lists your subscriptions; delivery problems have a checklist | Subscriptions, Troubleshooting analytics |
| Outbound messages | Message Log (Setup → Platform Operations → Monitoring → Message Log) — every message across all channels with status, attempts and last error, plus Resend and Release | Messaging channels and the message log |
| Workflow instances | View runs on the workflow's row — one instance per triggering, with status and incident count, down to the failing step | Build a workflow |
| Mobile sync failures | The Mobile Sync Failure entity — one record per terminal device-side failure, with the error and payload | Monitoring mobile sync failures |
How to read a failure
Read the exact status — "partial" means the good part committed. An import that finishes PartiallyCompleted has written its good rows; a sync cycle that ends PartiallyFailed has advanced cursors where work succeeded. Neither is an outage, and re-running the whole thing blindly can double-apply the part that worked. Treat a partial status as a pointer to the failed subset.
Drill to the smallest unit that carries the error. Imports record a message per failed row; integration runs record an error per run and an input/output snapshot per step, so you can see which step broke and with what data; Data Studio runs append a history entry with an error message on failure; the message log holds the last error per message. The error text at that smallest unit is the system's own guardrail talking — a validation, a mapping, a refused credential — and is almost always more specific than the top-level status.
Transient and deterministic failures behave differently. Transient integration errors are retried automatically with backoff before dead-lettering, so a single failure that cleared itself needs no action. Rejected credentials are deliberately not auto-retried — they persist until someone rotates or fixes the credential. A run of consecutive failures in any history is an outage to chase, not noise.
Retry on the mechanism's own terms. Each surface has its own retry with its own semantics: an import Retry re-submits all rows of the stored file, so id-less rows that succeeded the first time will be created again; an integration Replay re-processes the archived payload through the currently active flow and requires the run to be terminal first; a message Resend re-queues that one row; a faulted workflow is fixed and republished, then re-triggered. Read the semantics before clicking — the wrong retry duplicates work.
When nothing ran at all
An absent run is diagnosed differently from a failed one — silence has its own causes:
- A blank schedule is manual-only — legitimate configuration, and nothing will ever run on its own. An invalid cron expression is skipped silently, with no error anywhere; when something "never runs" on schedule, verify the expression first. See Refresh scheduling and monitoring.
- Schedules run in UTC — cron expressions and subscription times both. A job that runs at the "wrong" hour is usually off by exactly the local UTC offset.
- A subscription's first email arrives at the next occurrence — subscribing sends nothing immediately, and past slots are never replayed.
- A deactivated integration app stops its schedules and refuses new dispatches — the kill switch working as designed. Draft data models never build on schedule, whatever their cron says.
- An in-browser import dies with its tab — a run stuck in Processing forever usually means the tab closed; re-run it, and prefer the background mode for anything large.
- Push-based sync sites that stop sending produce no run and no error — the Sync Monitor's Sites column is the only place that silence becomes visible.