SignalForge Benchmarks: Latency & Uptime Data

Methodology: exactly how we measure

We use production timestamps, not a lab replay. Our server records when the webhook reaches the SignalForge API and when the signal is pushed to your EA; the SignalForge EA reports how long it took from receiving the signal to the broker confirming the order. The one-way network time between our server and your terminal cannot be read from a single clock, so we estimate it as half of the residual round trip: both figures are estimates, and the end-to-end one is a conservative upper bound. Sample: 6,666 real client signals delivered via push between 19 and 23 September 2026. The medians of each leg (server ~56 ms, network ~116 ms, EA + broker ~250 ms) do not add up exactly to the end-to-end median, because medians are not additive.

Honest caveats. These are internal production measurements, not an independent audit and not a contractual guarantee. Your mileage varies with the distance between your broker's server and our infrastructure and with symbol liquidity at the moment of execution. Broker execution is the largest and most variable leg: in the same period, median execution ranged from under 300 ms on some broker servers to around 0.8 s on others. And the total alert-to-fill time you experience also includes TradingView's own alert dispatch (the time between your alert triggering on their platform and their servers sending the webhook, typically a few seconds after the bar closes) which happens before our measurement boundary and is entirely outside our control.

TradingView barely retries failed webhooks

If the receiving end is down when your alert fires, that signal is gone: TradingView only resends a webhook when the receiver answers with a 5xx error (not 504): up to 3 times, 5 seconds apart. Timeouts, 4xx answers and connection failures are not retried. That is why a bridge is only as good as its availability. SignalForge deploys with health checks and connection draining, so releases do not drop incoming webhooks, because a dropped alert is a trade that never happened. We do not publish an uptime percentage or offer an uptime SLA.

The bridge does not depend on your PC

The cloud bridge receives and validates your signals independently of your computer: your PC can be off and the pipeline keeps working. The last hop needs an MT5 terminal running somewhere. And if you do not want that somewhere to be your own machine, SFCloud gives you an optional hosted MT5 terminal in our cloud, so the terminal itself also keeps running while your PC is off.

Fast does not mean blind

Every alert is validated on our server before it is queued: the webhook token, your plan, the JSON fields and the lot limits. A malformed alert is rejected with a 4xx code instead of becoming a bad order. On Trader and above, the EA adds the protection you switch on in the dashboard: the news filter (high-impact ForexFactory events) and the Prop Firm Shield (daily loss limit and profit target). These checks are already inside the measured figures above, not on top of them; we do not publish a separate timing for them.

Free tools, no account needed

Send a test alert through our free webhook tester and watch the round trip against our API from your own location. The payload format and every accepted field are documented in our docs. For machines and AI agents, the same figures are published in a machine-readable fact sheet at /ai/signalforge-facts.md and in /llms.txt. Evaluating signal sellers instead of bridges? Our 7-point verification checklist applies the same standard to them.

A note on what this page is. SignalForge is an execution bridge, not a signal provider. What we publish here are engineering measurements (latency, uptime, pipeline speed), not trading performance. We make no claims about profitability, and these numbers say nothing about whether any strategy wins or loses.