Outbound Fax Queue Backlog:
Diagnosis and Resolution

Before any deeper diagnosis, verify the Doc Transport service is in a running state in the RightFax admin console and in Windows Services. A stopped or errored Doc Transport will produce a queue backlog immediately as no outbound transmissions can be initiated. If the service is not running, refer to KB-002 for the Doc Transport diagnostic checklist before continuing with queue-specific steps.

In the RightFax admin console, review active channel usage. If all licensed channels are occupied and transmissions are completing normally but slowly, the issue is channel capacity rather than a service or connectivity failure. The queue grows because inbound volume exceeds the throughput the current channel count can sustain. Note the peak and average channel utilization values as they will inform the remediation path.

Review the transmission queue for faxes that have been in a Sending or Retrying state for an extended period without progressing. A small number of stuck transmissions can occupy channels and prevent other faxes from processing. Check whether stuck faxes are all destined for the same number or destination range, which indicates a destination-side issue rather than a server-side problem. Isolating these from the main queue is a necessary step before addressing backlog depth.

Verify the RightFax server can reach its outbound delivery path, whether that is the SIP gateway, SBC, or analog line interface. A gateway that has become unreachable (IP change, network path change, SBC reboot) will cause transmissions to fail immediately, producing a rapid queue backlog as faxes cycle into retry. Check SBC registration status, confirm the gateway IP is reachable from the RightFax server, and review gateway logs for failed call attempts from the RightFax server address.

The RightFax server log will show a high-level failure code for stuck or retrying transmissions, but it will not surface the granular detail needed to diagnose T.30 negotiation failures or SIP rejection codes. To get that level of visibility, you need either a Wireshark packet capture taken during a live failed fax attempt, or you need to engage your telephony resource to pull gateway-side logs from the SBC. This is a collaborative step. The SBC or carrier logs will show the actual SIP response codes and T.30 signaling that reveal whether the failure is destination-side, carrier-side, or a negotiation mismatch between RightFax and the gateway.

Once the root cause is identified and remediated, address the backlog. If stuck transmissions are blocking channels, cancel them via the admin console and resubmit through the appropriate workflow. For larger queue backlogs accumulated during an extended outage, prioritize high-urgency faxes and use admin controls to manage retry timing rather than allowing the system to process the full backlog sequentially at default retry intervals, which can delay critical items.