What JOX knows about every run.

Success or failure — binary and honest.

Every run is captured with precise timestamps, transactionally in the repository: start, end, duration, status. The return code is evaluated binary: 0 = OK, anything else = failure. That clarity makes template development fast and straightforward — no exit-code gymnastics, no mapping-table maintenance.

stdout / stderr on demand. Environment variables always.

stdout and stderr can be persisted in the JOX repository per job template via Load Output — unabridged, not just "last N lines". Default is off; the log file then stays on the server. Environment variables for every OS-job run, by contrast, are always captured — including the predefined variables that JOX sets, like JOX_JOB_ID, which give every run a unique, traceable identity.

Every statement. Data depending on statement type.

For SQL Actions, SQL Pipes and SQL Extracts, every executed statement is persisted — not the code from the template, but what actually went to the database after variable resolution. The data shows up directly in the JOX GUI:

• SQL Actions with SELECT: results appear automatically.
• SQL Pipes: per intermediate result configurable (Load Data).
• SQL Extracts: configurable with row limit (Load Data + Record Number Limit).

Which path, which account, which parameter was actually used.

System Functionalities are a template's abstract functionality bindings — things like bin_dir or billing_schema. They map per Location × Area to concrete directories or DB accounts. On top of that, classic JOX variables (e.g. order parameters) are resolved at runtime. In the run record you don't see the names — you see the concrete values: the path, the account, the parameter that was actually used.

Which files changed. Which DB state was visible before and after.

Which files did the run create or touch? And what was the database state visible immediately before and immediately after execution? This before/after view turns pure output persistence into a complete impact ledger — the basis for follow-up audits and re-run decisions.

What else was running in parallel.

From any run detail you jump straight into the Activity Report for the exact time window — and see all the jobs that ran in parallel (e.g. on the same Location or in the same Area). That is often the key piece of information when a job behaves differently under load than it does in isolation.

Which emails went to which recipients.

Every email that JOX sent in response to the run is persisted — with the full recipient list and the complete body. For area-dependent distribution lists, you see the concrete resolution — who was actually notified.