Diagnose job failures#
When a distribution job fails or completes with warnings, Reportworq keeps a per-run diagnostics archive you can read and trace. This guide is the administrator's path through those diagnostics, including how to send a run to support and the case where a job reports success but no output arrives.
When to use it. Whenever a run fails or flags warnings, or when a scheduled distribution completes but a recipient reports they got nothing.
Before you start#
- Open the run from Activity (the Details container), or from a job's Run History by opening the run and selecting its Performance tab, where the Advanced diagnostics section holds the same Log, Attachments, and Trace.
- Any log requires that job-history logging was on for the run. If it was off, the diagnostics show "No execution log for this run," which points you to the job's properties ▸ Diagnostics to enable it before re-running.
Read the diagnostics#
The diagnostics have three parts:
- Log. Each entry shows a line number, timestamp, elapsed time, and message. For errors, the entry expands to the exception message and stack trace. The view shows the first 250 entries with a Show Full Log expander.
- Attachments. The files the run produced, viewable and downloadable.
- Trace. HTTP and HAR traces, useful for pinning down which datasource call failed. This tab is empty unless Trace logging was enabled for the run. To capture it, turn Verbose and then Trace logging on in the Run Job Options before re-running. See Log diagnostics and support packets.
When a job succeeds but produces no output#
A run can report success and still deliver nothing. Work through these causes:
- The exception check gated the send. A source report's exception check is a send gate for that report's whole output. If no exception cell evaluated to the send condition, the job runs clean but sends nothing on purpose. The job log names it: "2 of 5 reports were held by the exception check and not sent" (the counts and the wording follow the number of reports held and in the run), with "[Not sent: exception check]" on each held output.
- Every worksheet was suppressed. Sheet suppression deletes a sheet when its formula is TRUE, and a provider report that returns no data auto-suppresses its sheet. If all sheets suppress, there is no file to deliver.
- A burst produced no recipients. If the burstable parameter or burst set resolved to an empty recipient list, there is nothing to send.
- The destination silently rejected it. A Microsoft 365 email from a non-default address without a "Send as" grant, a Slack bot not added to the target channel, or a network folder the service account cannot write to, can all fail quietly. Check the destination setup and the run's Log tab.
Open the run's Log tab and read it end to end; a "sent 0" or a suppression entry usually names the cause.
Send a run to support#
Sending a single run's own logs to Reportworq support is the fastest way to escalate one failure, because it packages exactly that execution's archive. This is the step customers most often get wrong, so work through it carefully.
From the run's header. In a job's Run History, open the failed run, then select Send to support at the top of the screen (it is also in the Actions menu). A failed run's one-line error offers Run again and Show details (the full message, the trace and what to try next, with a Copy button), but sending logs is done from the header.
You are asked to describe what you are sending, and you can add a support ticket number. Select Send to upload that execution's diagnostics archive over the secure support-upload path and notify the support desk, or Cancel to send nothing. You do not attach anything by email, and you do not need to zip anything yourself.
If you need the archive as a file instead, open the run's Actions menu and select Download history to download the run's execution database as a .zip. Use this to attach the archive to an existing support case, or when the instance cannot reach the support desk. If Send to support fails because the server cannot reach the internet, Reportworq offers this download for you.
For a broader packet that spans more than one file, or one that collects logs from every server in a cluster, build a support packet instead. See Log diagnostics and support packets.
Notes and limits#
- The Trace tab is empty unless Trace logging was on at run time, and Trace requires Verbose to be on.
- Enable Verbose logging before the run you want to diagnose, not after, so the detail is captured.
Going deeper. For author-side failure reading, see When a job fails. For symptom-to-fix pairs, see Troubleshooting index.
Feedback on this page
Comments, questions, requests, or something missing or unclear? Email us - the page you are on is filled in for you.
Email feedback on this pageOr write to support@reportworq.com directly.