# Private Synthetic Location Not Available for TCP (NAM) Monitors **URL:** \ **Category:** Troubleshooting\ **Tags:** synthetic-monitoring, private-synthetic-locations\ **Created:** [June 19, 2026, 12:00pm UTC](https://community.dynatrace.com/t/private-synthetic-location-not-available-for-tcp-nam-monitors/56213 "2026-06-19T12:00:38Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![hannahmac](https://avatars.discourse-cdn.com/v4/letter/h/dec6dc/32.png) [@hannahmac](https://community.dynatrace.com/u/hannahmac)\ **Post date:** [June 19, 2026, 12:00pm UTC](https://community.dynatrace.com/t/private-synthetic-location-not-available-for-tcp-nam-monitors/56213/1 "2026-06-19T12:00:38Z")
## Summary This article focuses on Dynatrace Synthetic Monitoring, specifically **Network Availability Monitors (NAM) using TCP**, and explains why a private Synthetic location may not be selectable when creating TCP monitors. It helps you understand the platform prerequisites and system‑level dependencies that determine whether **TCP monitoring is available from a private location** , and how to validate TCP connectivity using ActiveGate diagnostics and host-level testing. ## Problem After deploying **Synthetic‑enabled ActiveGates** and assigning them to a new private Synthetic location, the location appears as **Not supported** when attempting to create a TCP Network Availability Monitor. ### In the Dynatrace UI You may observe one or more of the following: - In **Synthetic → Private locations** , the private location shows a **Compatibility health alert** - **Network Availability (TCP)** is missing from the available monitor types under: _Classic Settings → Web and mobile monitoring → Private Synthetic locations → Edit location_ - The private location is marked as **Not supported** , with a message indicating that the location is not configured to execute this type of monitor ## Evidence in ActiveGate logs The ActiveGate diagnostic logs (`vuc-status.log`) indicate that TCP capability is unavailable, even though other protocols may still be operational. Example: ```auto MULTIPROTOCOL = { MULTIPROTOCOL_TCP = DiagnosticCaseDetail[isAvailable=false], MULTIPROTOCOL_DNS = DiagnosticCaseDetail[isAvailable=true], MULTIPROTOCOL_ICMP = DiagnosticCaseDetail[isAvailable=true] } ``` When `MULTIPROTOCOL_TCP` is reported as `isAvailable=false`, **TCP NAM monitors are automatically disabled for the private location**. This behavior is consistent with how Dynatrace enables NAM monitor types only when the required protocol capability is validated on the ActiveGate host. For information on finding the log see [Useful Synthetic ActiveGate logs](https://community.dynatrace.com/topic/214478) ## Troubleshooting steps Use the following steps to determine whether the limitation is due to Dynatrace configuration or host/network constraints. ### 1. Review ActiveGate diagnostic results - Check `vuc-status.log` for multi-protocol diagnostics - Confirm whether: - If false, the issue originates from the ActiveGate environment rather than Dynatrace configuration ### 2. Understand how TCP availability is validated A TCP NAM monitor works by **establishing a TCP connection to a specific port on a target host.** The ActiveGate must be able to: - Open an outbound TCP connection - Reach the target host over the network - Successfully complete a TCP handshake on the specified port If this fails during diagnostics, TCP monitoring will be disabled. ### 3. Verify TCP connectivity from the ActiveGate host Run connectivity tests directly from the ActiveGate host to the target endpoint. Examples: ```markup nc -vz ``` or ```markup telnet ``` Expected outcome: - Successful connection → TCP should be available - Connection refused / timeout → indicates network or service issue ### 4. Check firewall and network restrictions Ensure that: - Outbound traffic to the target port is **allowed** - Intermediate firewalls are not blocking TCP handshake traffic - Network routing between ActiveGate and target is correctly configured Common issues: - Denied outbound rules - Missing return route - Segmented networks without proper allowlisting ### 5. Validate service availability on the target Confirm that: - The target host is reachable - The specified port is open and listening - The service supports TCP connections Example checks: ```markup ss -tuln | grep ``` If the service is not listening, the TCP diagnostic will fail. ## Resolution Once the issue is identified and resolved: - Ensure TCP connectivity from the ActiveGate host is successful - Restart the ActiveGate service (if required to refresh diagnostics) - Re-check **Synthetic → Private locations** Expected result: - The private location no longer shows compatibility errors - **Network Availability (TCP)** becomes selectable - TCP NAM monitors can be created successfully ## After resolving the cause of the failure - Re-run diagnostics via ActiveGate logs to confirm: - Trigger an **on-demand execution** to validate monitor success - Confirm results in the Synthetic app ## What’s next - Consider creating multiple TCP requests within a single NAM monitor to validate multiple endpoints efficiently - Define appropriate thresholds for connection success or failure - Combine TCP NAM monitoring with ICMP or DNS checks for deeper network visibility ### Related reading 📖  [Create a NAM monitor (Dynatrace Docs)](https://docs.dynatrace.com/docs/observe/digital-experience/synthetic-monitoring/network-availability-monitors/create-a-nam-monitor) 📖  [Network availability monitoring overview](https://docs.dynatrace.com/docs/observe/digital-experience/synthetic-monitoring/network-availability-monitors/network-availability-monitoring) 📖  [Synthetic Monitoring Troubleshooting Map](https://community.dynatrace.com/topic/250426) 📖  [Manage Private locations](https://docs.dynatrace.com/docs/observe/digital-experience/synthetic-on-grail/synthetic-app/private-locations/manage-private-locations#health-status) 📖  [Useful Synthetic ActiveGate logs](https://community.dynatrace.com/topic/214478)