Check dated notices from Rithmic and your provider, matching the affected System and service to your error. Then compare application logs and local network behavior. One failed login, a stopped chart or a historical forum thread does not prove a current Rithmic-wide outage. This is a checking procedure, not a live status claim.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Where to check
- Open Rithmic System Advisories and inspect the date and affected environment of a relevant notice. The indexed page identifies maintenance and incident notices; this review did not establish a complete live status dashboard.
- Open your broker or funding provider's official help/status channel. Its notice may apply to its accounts, a particular connection or account provisioning.
- Check your platform vendor's current notices when only that application's connector fails.
- Preserve the exact application error and timestamp, including timezone.
Do not treat the absence of a notice as proof of normal service. An old maintenance notice is not evidence that the same event is happening now.
Compare scope before deciding
| Observation | What you can say | Next check |
|---|---|---|
| Current provider notice matches your System and service | A documented incident may explain the failure | Follow the notice and account-specific support instructions |
| Other apps and websites also lose connectivity | Local/network trouble is plausible | Check the network and preserve diagnostic evidence |
| One app fails while an appropriate RTrader connection works | The failure may involve the app, connector, session or permissions | Read that platform's logs and connection guide |
| Prices stop but order service appears connected | Data and trading need separate investigation | Check the exact contract, timestamp and entitlement |
| Several traders report a problem | A useful research lead | Seek a dated official confirmation and match scope |
The conclusions are deliberately conditional. Shared symptoms do not identify a root cause by themselves.
Read connection indicators as scoped evidence
The native session captured for this guide was Apex / Chicago Area. Its indicators were green at that moment. That observation does not establish availability for every Rithmic System, exchange, account or later time.
If your app is disconnected, confirm any positions and working orders through an available supported route or your provider. Do not assume they disappeared, remained protected or were canceled solely from a local status change.
Is it scheduled maintenance?
Rithmic’s current FAQ describes approximate routine windows, summarized in the linked maintenance guide. Use a current notice for the environment you actually use. Provider help articles give different maintenance descriptions and may use ambiguous timezone wording. Do not publish one permanent universal window or infer that login availability follows every exchange's trading hours. See weekend maintenance checks.
What to send to support
Provide the application/version, System/Gateway, exact failed service, timestamp/timezone, relevant log lines and whether other connections work. Link the notice you think applies and state why. Exclude passwords and redact private identifiers in shared captures.
Avoid changing risk settings, submitting test trades, accepting agreements or repeatedly switching gateways just to diagnose an outage. Reconnection and account verification are separate tasks, covered in the reconnect guide.
Common questions
Is a Reddit outage post enough to confirm today's problem?
No. Record its date and what users reported, then seek a matching official notice. Community reports guide investigation but do not establish current service-wide status.
Does an invalid-password response prove every server is online?
It means the attempt received that response. It does not test every data, order, history or account service.
Should I switch gateways during an incident?
Use an alternative only if it is supported for your System and the provider's instructions fit the situation. First assess active orders and local management dependencies.
Can a cloud automation bridge bypass the outage?
Do not assume that. Check the bridge's actual Rithmic route and documented failure handling. Cloud hosting does not prove the underlying service is available.