What is on the System page?
Every scheduled job the platform runs: the fifteen-minute store sync, the nightly heavy sources, the webhook listeners, the report generators, the measurement jobs. For each, its cadence, its current health, when it last succeeded, what that run produced, and a full history of runs with durations and outcomes.
It is the operational truth of the platform, kept separately from the business surfaces, so an owner can always answer whether today's numbers are today's.
- The fifteen-minute commerce sync, with its last successful run and what it produced.
- The nightly heavy sources: returns, behaviour analytics, search console and the rest.
- The webhook listeners, such as inventory, which update in real time.
- The report and measurement jobs that write the Executive Report and the Results verdicts.
- A full run history per job, with durations, outcomes and row counts.
Why health is judged per cadence
A job that should run every fifteen minutes and last ran an hour ago is unhealthy. A job that runs nightly and last ran nine hours ago is fine. A single rule for both would either cry wolf or miss the failure, so each job is judged against its own schedule.
That makes the page readable at a glance. Everything green means everything ran on its own terms, which is a stronger statement than everything ran recently.
It also means a job added later inherits the right standard automatically. The cadence is declared with the job, so the page never needs a separate rule table that drifts out of date as the platform grows.
A run that produced nothing is not a success
The most dangerous failure in a data platform is the job that completes without error and writes no rows. Downstream, the numbers simply stop moving, and nothing looks broken. The run ledger records what each run produced, so a sync that returned zero records when it should have returned hundreds is visible.
This is the difference between monitoring a process and monitoring an outcome, and it is why the ledger records output rather than just status.
How does the ledger back the trust footer?
Every freshness claim in a chat answer's trust footer traces to this ledger: the source's last successful run is the freshness shown. There is one place where the truth about runs lives, and every surface that talks about freshness reads it.
When an answer says a source is stale, the reader can open System, see the failed runs, and know what to fix, rather than wondering whether the warning was generic.
What happens to advice when a job stops?
The affected data domain is marked degraded, and the recommendations built on it are withheld or labelled. A reorder proposal that depends on an inventory feed which failed overnight does not reach the Morning Brief as if nothing had happened; the brief says the source is degraded and which role has gone quiet.
That behaviour is what turns an operational page into a safety mechanism. The platform would rather say less than say something confident and wrong.
Who reads it on ftes.ai?
The Data Trust FTE reads this surface as its own source of truth, publishes a trust state per data domain, and holds every other role to it. The owner reads it when a figure looks wrong, and the answer is usually here rather than in the analytics.
For a brand, the useful habit is simple: when something looks off, open System first. Most surprises in an analytics platform are a run, not a calculation.
What does a healthy platform look like here?
Every job green against its own cadence, each with a recent successful run that produced a sensible number of rows. A nightly job that returned nothing on a quiet Sunday is normal; the same job returning nothing on a Friday is not, and the row counts are what make the difference visible.
The pattern to watch is a job whose durations creep up week by week. That is usually a source growing faster than its window, and it is the early warning that precedes an actual failure by some weeks.