Connection preflight
A connection preflight is a step-by-step diagnostic that exercises a market-data connection one stage at a time, gateway, system name, login, subscription and first tick, and reports what each stage measured. It separates a refused route from refused credentials and from an accepted feed that is simply silent.
Senzoukria · Glossary · Updated September 2026
The stages
| Stage | Question | What a pass proves |
|---|---|---|
| Gateway reachable | Did the gateway URL answer? | Network path exists; no firewall, VPN or proxy blocked it |
| System recognised | Does this gateway serve the named system? | The system name is on the gateway's live list |
| Gateway and system agree | Is the route correct? | A later refusal is not a routing error |
| Authentication | Did the broker accept the login? | Credentials and entitlement for that system |
| Data subscription | Was the symbol subscription accepted? | Market-data permission for that symbol |
| First tick received | Did a tick arrive within the wait? | Data flows now; a quiet market can still fail this |
Why a staged check beats a single error
Refusals that look identical on screen have had different causes: a wrong gateway, a system name that moved, an expired password, a missing data entitlement, a contract that expired and still accepts subscriptions. A diagnostic that stops at the first failing stage and names what it measured turns a vague login failed into a fact that support or the provider can act on. The Rithmic guide lists the account-side items to confirm separately: system name, permitted third-party applications, depth and history availability, session limits and routing permissions.
In Senzoukria
The connections screen has a Connection diagnostic with a Run the diagnostic button, a Run again button and Copy the result. Each stage reports one of passed, failed or Not run with the reason, for example Not run, no password saved on this connection. Its note states the method: it reports what it measured and lists possible causes by frequency; it never designates one as certain.
When every stage passes but no tick arrives, the diagnostic shows Everything was accepted, no data is arriving, and lists causes most frequent first: the market is closed for this contract, the symbol is no longer the front-month contract, and others. The copy of the result is meant to be pasted into a support request together with the requested interval.
Common mistakes
- Changing indicators or reinstalling the application before running the diagnostic.
- Reading a passed subscription as proof of historical coverage; history is a separate entitlement.
- Running the check on a weekend and concluding the account is broken because no tick arrived.
- Sending only the final verdict to support rather than the copied stage-by-stage result.
Related
This page in other languages
Frequently asked questions
- The diagnostic passed every stage but the chart is empty. Why?
- An accepted subscription proves permission, not activity. The contract may be closed for its session, or the symbol may be an expired expiry that still accepts subscriptions and trades nothing. Check the session clock and the front-month contract first; the diagnostic lists these causes in order of frequency without asserting one.
- Does the preflight apply to a bridge connection?
- The staged gateway, system and login checks are for direct connections. A NinjaTrader or Quantower bridge is checked differently: the bridge indicator must be running on one chart, the local port must be free, and the history the bridge announced must match what was received. The Quantower guide gives the PowerShell command that confirms the listener.