How a report is produced

Report tickets divide almost evenly between "it never arrived" and "the numbers are wrong", and the two have completely different causes.

It is a queued job, not a download

Requesting a report publishes a message. A separate rendering service consumes it, builds the document, and stores the file. Only then does it appear in Reports Management.

request  →  queued  →  renderer consumes  →  document built  →  stored  →  downloadable

Nothing about that is instant, and a large report legitimately takes minutes. The request returning successfully means the job was accepted, not that the report exists.

"The report never arrived"

Check in this order:

1. Is the job queued or failed? Process Manager distinguishes the two immediately. PENDING means nothing consumed it; FAILED means the renderer ran and errored.
2. Are other queued things also stalled? Reports, imports and outbound email share the same broker. If all three are stuck, the report is a symptom, not the problem.
3. Was it scheduled rather than requested? A scheduled report runs on its own timetable — usually overnight — and did not run because it was not yet due.
4. Was it emailed to a list you are not on? Scheduled reports go to a recipient list configured on the schedule, which is maintained separately from user accounts. People who join or leave a team do not get added or removed automatically.

A report that failed for one scope and succeeds for a narrower one is usually a size problem: a report covering the entire estate over a long period can exceed what the renderer will complete.

"The numbers are wrong"

Nearly always one of four things, and only the last is a defect.

The report is older than the screen. A report is a snapshot at the moment it ran. SLA states in particular change with the passage of time alone — a finding that was approaching expiry when the report ran is overdue today, with no data edit involved. Check the generation timestamp first; it resolves this immediately.

The scope differs. The report covered one audit, one asset group or one period. The screen is showing something wider or narrower. This is the most common cause of a disagreement in absolute counts.

Inclusion rules differ. Reports may exclude findings awaiting approval, or audits not marked as considered — the same rules that make dashboards disagree with module screens. See the two-status-fields workflow.

The template selects different fields. A custom template that groups by a different property will legitimately produce different subtotals from the same data.

Regenerating is the fastest diagnostic

If a regenerated report matches the screen, the original was simply old, and nothing is wrong. That single step resolves a large share of these tickets before any investigation.

Templates apply going forward

Editing a template changes future reports. Documents already produced are files on disk and do not change retrospectively — which is the point, since a report already sent to an auditor must not silently alter afterwards.

If someone needs the old report in the new format, it has to be regenerated, and it will then also pick up any data changes since the original run.

What to collect before escalating

• The report type and the template used
• The generation timestamp and the scope it was run for
• The queue status, if it never arrived
• Whether a regeneration reproduces the discrepancy

The last one matters most: a discrepancy that disappears on regeneration was a timing artefact, and one that survives it is worth investigating.