Skip to main content

Windows network latency

Last updated on

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.

Run your first experiment

If you have not configured the chaos infrastructure yet, go to Quickstart to install the chaos infrastructure and run an experiment end to end.

Use cases​

  • 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​

  • Windows chaos infrastructure: Install the chaos agent on the target VM. Go to Windows requirements and security considerations.
  • Administrator privileges: Network latency is an Advanced fault and requires the agent to run as administrator.

Supported environments​

PlatformSupport status
Windows Server VMs with the Windows chaos agent installedSupported
Linux VMsNot supported (use VMware network latency)

Permissions required​

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

Fault tunables​

Chaos parameters

TunableDescriptionDefault
DURATIONTotal duration of the fault as a Go duration string (for example 30s).30s
NETWORK_LATENCYLatency to inject in milliseconds.2000
NETWORK_JITTERRandom jitter added on top of the latency, in milliseconds.0
DESTINATION_HOSTSComma-separated destination hostnames to slow.""
DESTINATION_IPSComma-separated destination IPs/CIDRs to slow.""
DESTINATION_PORTSComma-separated destination ports to filter on.""
NETWORK_PROTOCOLSComma-separated protocols (tcp, udp, icmp).""
NETWORK_WHITELIST_DESTINATION_HOSTSHostnames excluded from latency.""
NETWORK_WHITELIST_DESTINATION_IPSIPs/CIDRs excluded from latency.""
NETWORK_WHITELIST_DESTINATION_PORTSPorts excluded from latency.""
RAMP_TIMEWait period in seconds before and after the fault.0

Tunables that apply to every fault are documented in common tunables for all faults.

Fault execution in brief​

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​

  • 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.
When the fault ends

The chaos agent removes the network filter. Latency returns to baseline within seconds.

Signals to watch​

  • End-to-end latency: Use an HTTP probe from outside the VM.
  • Caller behavior: Use a Prometheus probe on caller-side timeout and circuit-breaker metrics.

Verify the fault execution effect​

  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​

  • 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​

  • 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​

Windows network latency has no observable effect in Harness Chaos Engineering

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.

Windows network latency fails with access denied

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