DOCUMENTATION / KNOWLEDGE BASE

Built for engineers. Written for clarity.

Implementation notes for infrastructure discovery, connectivity and monitoring. These are starter guides, not provider-specific production instructions.

01 / PROJECT INTAKE

Start with a technical brief.

Before provisioning, define the workload, trading endpoints, target origin, expected traffic and operational contacts.

Workload inventory and application requirements

Required endpoint destinations and approvals

Bandwidth, port and address requirements

Availability and recovery objectives

Maintenance and change-control preferences

02 / CONNECTIVITY

Document every handoff.

For each authorised broker, LP or ECN, record the physical or virtual handoff, carrier, peering requirement, interface speed, addressing, routing preferences and acceptance tests.

Accurate trading-path measurements require the approved gateway IP or hostname, transport port and protocol, authorised testing rights, and a probe located at the intended network origin. Public broker website checks are not offered.

03 / RESILIENCE

Design A/B paths deliberately.

Where feasible, separate routers, switch fabrics, physical connections and server interfaces. Record what still forms a common failure domain—including shared power, cross-connects or upstream providers.

View illustrative topology →

04 / TELEMETRY INTEGRATION

Connect a monitoring source.

The status and FX latency dashboards read /.netlify/functions/telemetry. Set UPTICKS.COM_TELEMETRY_URL on your Netlify project to an HTTPS endpoint returning the JSON format below. The proxy fetches data server-side to avoid exposing your telemetry API address in the browser.

Example schema only — numbers and status values below are fictional demonstration values and are not shown on the live site.

Example telemetry payload · JSON

{
  "updatedAt": "2026-11-01T09:00:00Z",
  "sites": {
    "london": {"state": "operational", "detail": "agent confirmed"},
    "amsterdam": {"state": "degraded", "detail": "investigating link"}
  },
  "components": [
    {"name": "London edge routers", "state": "operational"}
  ],
  "incidents": [
    {"id": "inc-001", "title": "Path investigation",
     "status": "investigating", "startedAt": "2026-11-01T08:45:00Z"}
  ],
  "latency": {
    "results": [
      {"endpoint": "Approved FIX gateway", "origin": "london",
       "protocol": "FIX", "medianMs": 0.72, "p95Ms": 1.04,
       "lossPercent": 0, "sampledAt": "2026-11-01T09:00:00Z"}
    ],
    "history": [
      {"origin": "london", "timestamp": "2026-11-01T09:00:00Z", "medianMs": 0.72}
    ]
  }
}

Endpoint access should be read-only, restricted to public-safe aggregated metrics, and protected by your monitoring architecture. The deployed function rejects insecure upstream URLs and reports unconfigured feeds as unknown.

05 / MEASUREMENT SCOPE

Make results reproducible.

Every trading-latency measurement should identify its origin, endpoint, protocol, direction, sampling window, median, p95 and timestamp. Keep application order-execution statistics separate from network RTT.

Agent location and timestamp documented

Approved gateway IPs/hostnames, ports and FIX/MT4/MT5/LP testing permissions

Real sample size and reporting window

Do not publish synthetic benchmarks as operational data

06 / OPERATIONS

Plan escalation before incidents.

Agree severity levels, monitoring ownership, contact routes, evidence capture, maintenance notifications and recovery test schedules. Confirm the specific SLA with your service order.

Security and SLA framework →

Technical discovery

Need help mapping your design?

Share endpoint requirements, handoff details and target recovery objectives.

Arrange a technical session