> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-latency.md).

# Windows network latency

Windows network latency is a Windows chaos fault that adds `NETWORK_LATENCY` milliseconds (with optional `NETWORK_JITTER`) of latency to egress traffic from the target Windows VM to the destinations listed in `DESTINATION_HOSTS`/`DESTINATION_IPS` on ports `DESTINATION_PORTS` and protocols `NETWORK_PROTOCOLS` for `DURATION`, then removes the rule. The fault runs through the Windows chaos agent installed as a service on the target VM. Use the `NETWORK_WHITELIST_*` tunables to spare specific destinations from the latency.

Use this fault to test how a workload on a Windows VM behaves when a downstream dependency becomes slow: whether retries and timeouts work, whether circuit breakers open correctly, and whether monitoring detects the regression within the alerting SLA.

{% hint style="info" %}
**RUN YOUR FIRST EXPERIMENT**

If you have not configured the chaos infrastructure yet, go to [Quickstart](/resilience-testing/chaos-engineering/new-to-chaos-engineering/quickstart.md) to install the chaos infrastructure and run an experiment end to end.
{% endhint %}

***

### Use cases <a href="#use-cases" id="use-cases"></a>

* **Slow dependency:** When latency to a specific dependency spikes, does the caller honour its timeout and circuit-breaker policy?
* **End-to-end SLO:** Does the end-user SLO degrade gracefully?
* **Retry storms:** Does retry logic amplify load when the dependency is slow?

***

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

* **Windows chaos infrastructure:** Install the chaos agent on the target VM. Go to [Windows requirements and security considerations](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-chaos-permissions.md).
* **Administrator privileges:** Network latency is an Advanced fault and requires the agent to run as administrator.

***

### Supported environments <a href="#supported-environments" id="supported-environments"></a>

| Platform                                                  | Support status                                                                                                                                           |
| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows Server VMs with the Windows chaos agent installed | Supported                                                                                                                                                |
| Linux VMs                                                 | Not supported (use [VMware network latency](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-network-latency.md)) |

***

### Permissions required <a href="#permissions-required" id="permissions-required"></a>

This fault is classified as **Advanced** and requires the chaos agent to run as administrator on the target VM.

***

### Fault tunables <a href="#fault-tunables" id="fault-tunables"></a>

**Chaos parameters**

| Tunable                               | Description                                                              | Default |
| ------------------------------------- | ------------------------------------------------------------------------ | ------- |
| `DURATION`                            | Total duration of the fault as a Go duration string (for example `30s`). | `30s`   |
| `NETWORK_LATENCY`                     | Latency to inject in milliseconds.                                       | `2000`  |
| `NETWORK_JITTER`                      | Random jitter added on top of the latency, in milliseconds.              | `0`     |
| `DESTINATION_HOSTS`                   | Comma-separated destination hostnames to slow.                           | `""`    |
| `DESTINATION_IPS`                     | Comma-separated destination IPs/CIDRs to slow.                           | `""`    |
| `DESTINATION_PORTS`                   | Comma-separated destination ports to filter on.                          | `""`    |
| `NETWORK_PROTOCOLS`                   | Comma-separated protocols (`tcp`, `udp`, `icmp`).                        | `""`    |
| `NETWORK_WHITELIST_DESTINATION_HOSTS` | Hostnames excluded from latency.                                         | `""`    |
| `NETWORK_WHITELIST_DESTINATION_IPS`   | IPs/CIDRs excluded from latency.                                         | `""`    |
| `NETWORK_WHITELIST_DESTINATION_PORTS` | Ports excluded from latency.                                             | `""`    |
| `RAMP_TIME`                           | Wait period in seconds before and after the fault.                       | `0`     |

Tunables that apply to every fault are documented in [common tunables for all faults](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md).

***

### Fault execution in brief <a href="#fault-execution-in-brief" id="fault-execution-in-brief"></a>

The Windows chaos agent on the target VM installs a network filter that adds `NETWORK_LATENCY` ms (+/- `NETWORK_JITTER` ms) to egress traffic matching `DESTINATION_HOSTS`/`DESTINATION_IPS`, `DESTINATION_PORTS`, and `NETWORK_PROTOCOLS` (minus the whitelist) for `DURATION`, then removes the filter.

***

### Expected behavior during fault execution <a href="#expected-behavior-during-fault-execution" id="expected-behavior-during-fault-execution"></a>

* Egress latency from the VM to matched destinations rises by `NETWORK_LATENCY` ms.
* Upstream callers see higher round-trip latency.
* After the duration ends, the filter is removed and latency returns to baseline.

{% hint style="info" %}
**WHEN THE FAULT ENDS**

The chaos agent removes the network filter. Latency returns to baseline within seconds.
{% endhint %}

#### Signals to watch <a href="#signals-to-watch" id="signals-to-watch"></a>

* **End-to-end latency:** Use an [HTTP probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/http-probe.md) from outside the VM.
* **Caller behavior:** Use a Prometheus probe on caller-side timeout and circuit-breaker metrics.

***

### Verify the fault execution effect <a href="#verify-the-fault-execution-effect" id="verify-the-fault-execution-effect"></a>

1. **Run `Test-NetConnection <DESTINATION_HOSTS_entry> -InformationLevel Detailed` from the target VM.**

   `PingReplyDetails.RoundtripTime` should rise by `NETWORK_LATENCY` during the chaos window.
2. **Run a quick HTTP call from a peer machine.**

   Round-trip should rise during the window.

***

### Recovery and cleanup <a href="#recovery-and-cleanup" id="recovery-and-cleanup"></a>

* **End of duration:** The chaos agent removes the filter.
* **Abort:** Stopping the experiment also removes the filter.
* **Manual recovery:** Restart the chaos agent service (`Restart-Service HCEAgent`) if filters survive.

***

### Limitations <a href="#limitations" id="limitations"></a>

* **Egress only:** The rule affects egress traffic from the VM. Ingress is not slowed.
* **DNS at start:** `DESTINATION_HOSTS` is resolved when the rule is installed.
* **Administrator required:** This is an Advanced fault and requires the agent to run as administrator.

***

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

<details>

<summary>Windows network latency has no observable effect in Harness Chaos Engineering</summary>

Verify DESTINATION\_HOSTS or DESTINATION\_IPS actually match the traffic you are measuring. If the workload uses a proxy or VPN, the rule may not match the real egress path.

</details>

<details>

<summary>Windows network latency fails with access denied</summary>

The chaos agent must run as administrator to install network filters. Reinstall the agent as administrator and retry.

</details>

***

### Related faults <a href="#related-faults" id="related-faults"></a>

* [Windows network loss](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-network-loss.md): Drop packets instead of delaying them.
* [Windows blackhole chaos](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-blackhole-chaos.md): Block traffic entirely instead of slowing it.