Diagnose job failures#

When a 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 report's Run History by selecting View diagnostics on the run to open its "Report & diagnostics" view. Both host the same Log, Attachments, and Trace diagnostics.
• 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 Report Properties ▸ Diagnostics to enable it before re-running.

Read the diagnostics#

The Diagnostics view has three tabs:

• 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 report's exception check is a whole-report send gate. If no exception cell evaluated to the send condition, the job runs clean but sends nothing on purpose.
• 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. There are two entry points, and both upload the same execution logs.

From the run's history card. In a report's Run History, find the failed run and select Send logs to support on its card. (The same card also offers Run again.)

From the diagnostics view. Open the run's View diagnostics, then select Send to support in the toolbar. Use this when you are already reading the Log, Attachments, or Trace tabs.

Either way, Reportworq uploads that execution's diagnostics archive over the secure support-upload path and notifies the support desk. 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, select Export logs 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.

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 report-author-side failure reading, see When a job fails. For symptom-to-fix pairs, see Troubleshooting index.