# How to Prepare Before Contacting ISP Support

Source: https://urbanx.co.za/knowledge-hub/support-diagnostics/prepare-before-contacting-support

**Answer:** Before contacting ISP support, confirm ONT status, test via Ethernet, record timestamps, run a wired speed test, capture WinMTR or traceroute logs, and identify whether the issue is full outage or performance-related. Structured preparation accelerates classification and escalation.

Part of [Gamer-Centric Support & Intelligent Diagnostics](https://urbanx.co.za/knowledge-hub/support-diagnostics) · 9 min read · by UrbanX Support Engineering

## Why Preparation Matters

In South Africa’s open-access fibre model:

- ISPs validate the issue
- FNOs repair confirmed access-layer faults
- Escalation requires structured evidence

If you contact support without diagnostics, the process resets to basic validation, delaying resolution. Preparation shortens the diagnostic flow and improves escalation acceptance.

## Pre-Contact Checklist

1. **Check ONT Status**
   - Look at the ONT (Optical Network Terminal): Power light should be on, PON/Fibre light should be stable (not flashing red), LOS (Loss of Signal) should be off.
   - If LOS is red, note the exact time. Do not repeatedly power-cycle before recording timestamps.
2. **Confirm WAN Sync**
   - Check your router: Is WAN connected? Does the router show "Connected"? Are you receiving a public or private IP?
   - If WAN is down, this may indicate an access-layer issue.
3. **Test via Ethernet (Mandatory)**
   - Connect a device directly to the router using Ethernet. Do not test over WiFi.
   - WiFi instability can mimic packet loss, jitter, and speed fluctuation. Ethernet isolation removes LAN variability.
4. **Run a Wired Speed Test**
   - Run a speed test while connected via Ethernet. Record download speed, upload speed, and latency.
   - If speeds are normal but gaming is unstable, the issue may not be throughput-related.
5. **Capture Traceroute or WinMTR (Performance Issues)**
   - If experiencing lag or packet loss: run WinMTR for 5–10 minutes, or run traceroute to the affected server, and capture full output.
   - Log collection reference: [What Logs to Provide for Packet Loss Issues](/knowledge-hub/support-diagnostics/logs-for-packet-loss-issues). This allows immediate packet loss classification.
6. **Run a Continuous Ping (If Intermittent)**
   - For intermittent instability: run continuous ping to a stable target (e.g., local gateway or DNS), let it run during the issue, and capture spikes or drops.
   - Continuous ping reveals intermittent packet loss patterns.
7. **Record Exact Timestamps**
   - Provide: date, start time of issue, end time (if resolved), and whether issue is ongoing.
   - Timestamps allow support to cross-check monitoring logs, identify area-level faults, and validate escalation timing.
8. **Identify Scope of Impact**
   - Clarify: full internet outage? Only one game affected? Only one device affected? All devices affected?
   - If only one game is affected, server-side issues may be involved. If entire connection drops, access-layer fault is more likely.

## Diagnostic Preparation Summary

| Check | Why It Matters |
| --- | --- |
| ONT Status | Detects signal loss |
| WAN Sync | Identifies access-layer instability |
| Ethernet Test | Eliminates WiFi interference |
| Wired Speed Test | Confirms throughput |
| WinMTR / Traceroute | Locates packet loss |
| Continuous Ping | Detects intermittent drops |
| Timestamps | Correlates logs |
| Scope of Impact | Classifies issue layer |

> **INFO:** Prepared data reduces back-and-forth questioning.

## South African Open-Access Context

Because UrbanX operates across multiple FNOs:

- Escalation must include validated evidence
- Insufficient diagnostics can result in rejection
- Repeat validation extends downtime

Preparation ensures that if escalation is required, it proceeds without reset. Escalation reference: [How to Run Basic Diagnostics Before Escalation](/knowledge-hub/support-diagnostics/basic-diagnostics-before-escalation).

## What Slows Resolution

Common issues that delay the support process:

- Testing only over WiFi
- No timestamps provided
- No logs attached
- Rebooting repeatedly before logging time
- Vague descriptions ("laggy" or "slow")

> **WARNING:** Support must restart structured validation if data is incomplete.

## Key Term: WAN Sync

- **WAN Sync** — The router’s connection state with the fibre access network. Loss of WAN sync often indicates an access-layer issue requiring structured escalation.

## Frequently Asked Questions

**Should I reboot everything before contacting support?**

Reboot once if instructed. Repeated reboots can erase useful diagnostic history.

**Is a speed test enough?**

No. Speed tests do not reveal packet loss location.

**Why is Ethernet mandatory for testing?**

WiFi instability frequently produces false-positive packet loss.

**What if my ONT shows LOS red?**

Record the timestamp and contact support immediately.

**Does preparation guarantee faster repair?**

It reduces diagnostic delay and prevents escalation rejection, but FNO repair scheduling still applies.