diff --git a/docs/agents/sematext-agent/index.md b/docs/agents/sematext-agent/index.md
index dee577265..e30740dc2 100644
--- a/docs/agents/sematext-agent/index.md
+++ b/docs/agents/sematext-agent/index.md
@@ -18,4 +18,5 @@ other metric sources.
 - [Inventory tracking](/docs/monitoring/inventory) of your whole infrastructure including packages, server details, container metadata and more.
 - [Process monitoring](/docs/monitoring/processes) that helps out identifying top CPU or memory consumers.
 - [Service discovery](/docs/monitoring/autodiscovery/) and automated monitoring for vanilla Docker and Kubernetes workloads.
+- [Network Map](/docs/network-map/) for visualizing infrastructure topology and service connections using eBPF-powered network insights.
 - [Logs discovery](/docs/logs/discovery/intro/) and parsing.
diff --git a/docs/fleet/index.md b/docs/fleet/index.md
index 87a48bb8d..4cf317fac 100644
--- a/docs/fleet/index.md
+++ b/docs/fleet/index.md
@@ -1,7 +1,7 @@
 title: Fleet and Discovery Overview
 description: Overview of Fleet and Discovery - Fleet & Discovery management panel
 
-[Fleet](/docs/fleet/fleet) & [Discovery](/docs/fleet/discovery) are two major components of your infrastructure [monitoring](/docs/monitoring/) and [log management](/docs/logs/). Think of them as the 'eyes and ears' of your entire infrastructure. They enable you to monitor the health, performance, and configuration changes of your infrastructure.  See the video below for a quick overview.
+[Fleet](/docs/fleet/fleet) & [Discovery](/docs/fleet/discovery) are two major components of your infrastructure [monitoring](/docs/monitoring/) and [log management](/docs/logs/). Think of them as the 'eyes and ears' of your entire infrastructure. They enable you to monitor the health, performance, and configuration changes of your infrastructure. For a visual representation of your infrastructure topology and service connections, see [Network Map](/docs/network-map/). See the video below for a quick overview.
 
 <div class="video_container">
 <iframe src="https://www.youtube.com/embed/AzWtbPJ7-aU" 
diff --git a/docs/images/network-map/network-map-bare-metal-hosts.png b/docs/images/network-map/network-map-bare-metal-hosts.png
new file mode 100644
index 000000000..8988f3131
Binary files /dev/null and b/docs/images/network-map/network-map-bare-metal-hosts.png differ
diff --git a/docs/images/network-map/network-map-color-by.png b/docs/images/network-map/network-map-color-by.png
new file mode 100644
index 000000000..f27b610c5
Binary files /dev/null and b/docs/images/network-map/network-map-color-by.png differ
diff --git a/docs/images/network-map/network-map-connection-details.png b/docs/images/network-map/network-map-connection-details.png
new file mode 100644
index 000000000..98f99cc17
Binary files /dev/null and b/docs/images/network-map/network-map-connection-details.png differ
diff --git a/docs/images/network-map/network-map-enable-no-infra-app.png b/docs/images/network-map/network-map-enable-no-infra-app.png
new file mode 100644
index 000000000..1aa6d22c7
Binary files /dev/null and b/docs/images/network-map/network-map-enable-no-infra-app.png differ
diff --git a/docs/images/network-map/network-map-enable-ready.png b/docs/images/network-map/network-map-enable-ready.png
new file mode 100644
index 000000000..3c511322c
Binary files /dev/null and b/docs/images/network-map/network-map-enable-ready.png differ
diff --git a/docs/images/network-map/network-map-filters.png b/docs/images/network-map/network-map-filters.png
new file mode 100644
index 000000000..df58edf58
Binary files /dev/null and b/docs/images/network-map/network-map-filters.png differ
diff --git a/docs/images/network-map/network-map-k8s-cluster-details.png b/docs/images/network-map/network-map-k8s-cluster-details.png
new file mode 100644
index 000000000..447d0cd1f
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-cluster-details.png differ
diff --git a/docs/images/network-map/network-map-k8s-clusters.png b/docs/images/network-map/network-map-k8s-clusters.png
new file mode 100644
index 000000000..2e54533f0
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-clusters.png differ
diff --git a/docs/images/network-map/network-map-k8s-container-details.png b/docs/images/network-map/network-map-k8s-container-details.png
new file mode 100644
index 000000000..95d7401fe
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-container-details.png differ
diff --git a/docs/images/network-map/network-map-k8s-containers.png b/docs/images/network-map/network-map-k8s-containers.png
new file mode 100644
index 000000000..cd61d2605
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-containers.png differ
diff --git a/docs/images/network-map/network-map-k8s-node-details.png b/docs/images/network-map/network-map-k8s-node-details.png
new file mode 100644
index 000000000..63174d601
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-node-details.png differ
diff --git a/docs/images/network-map/network-map-k8s-nodes.png b/docs/images/network-map/network-map-k8s-nodes.png
new file mode 100644
index 000000000..8332772e7
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-nodes.png differ
diff --git a/docs/images/network-map/network-map-k8s-pods.png b/docs/images/network-map/network-map-k8s-pods.png
new file mode 100644
index 000000000..716b1bd81
Binary files /dev/null and b/docs/images/network-map/network-map-k8s-pods.png differ
diff --git a/docs/images/network-map/network-map-outdated-agents.png b/docs/images/network-map/network-map-outdated-agents.png
new file mode 100644
index 000000000..7e4f9ae88
Binary files /dev/null and b/docs/images/network-map/network-map-outdated-agents.png differ
diff --git a/docs/images/network-map/network-map-quick-guide.png b/docs/images/network-map/network-map-quick-guide.png
new file mode 100644
index 000000000..23f5cdce9
Binary files /dev/null and b/docs/images/network-map/network-map-quick-guide.png differ
diff --git a/docs/images/network-map/network-map-service-details.png b/docs/images/network-map/network-map-service-details.png
new file mode 100644
index 000000000..bc15e1bc1
Binary files /dev/null and b/docs/images/network-map/network-map-service-details.png differ
diff --git a/docs/images/network-map/network-map-services-view.png b/docs/images/network-map/network-map-services-view.png
new file mode 100644
index 000000000..36b4af541
Binary files /dev/null and b/docs/images/network-map/network-map-services-view.png differ
diff --git a/docs/images/network-map/network-map-thresholds.png b/docs/images/network-map/network-map-thresholds.png
new file mode 100644
index 000000000..3f932bbe9
Binary files /dev/null and b/docs/images/network-map/network-map-thresholds.png differ
diff --git a/docs/index.md b/docs/index.md
index 5e041c9ee..b36bf7758 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -30,9 +30,17 @@ _If you're new here, read below for a high-level overview of Sematext._
     ---
 
     Distributed tracing with OpenTelemetry for microservices
-    
+
     [:octicons-arrow-right-24: Learn more](/docs/tracing)
 
+-   :fontawesome-solid-diagram-project:{ .lg .middle .network-map-icon } __Network Map__
+
+    ---
+
+    Visualize infrastructure topology and service connections
+
+    [:octicons-arrow-right-24: Learn more](/docs/network-map)
+
 -   :fontawesome-solid-gauge-high:{ .lg .middle .experience-icon } __Experience__
 
     ---
@@ -92,9 +100,9 @@ _If you're new here, read below for a high-level overview of Sematext._
 -   :fontawesome-solid-server:{ .lg .middle .fleet-icon } __Fleet & Discovery__
 
     ---
-    
+
     Agent fleet, discovery & automatic setup of services and logs
-    
+
     [:octicons-arrow-right-24: Learn more](/docs/fleet)
 
 </div>
diff --git a/docs/monitoring/autodiscovery.md b/docs/monitoring/autodiscovery.md
index 3336cf5c0..f1ea19e30 100644
--- a/docs/monitoring/autodiscovery.md
+++ b/docs/monitoring/autodiscovery.md
@@ -2,7 +2,7 @@ title: Sematext Service Discovery
 description: Sematext Autodiscovery Monitoring automatically scans for services that can be monitored using Sematext Agent and, depending on your configuration, automatically sets up monitoring agents. 
 
 The centerpiece of Service Discovery is [Sematext Agent](/docs/agents/sematext-agent). When Sematext Agent is installed and running on a server/node/instance it scans for services that can be monitored by Sematext
-[supported integrations](/docs/monitoring/autodiscovery/#which-integrations-allow-autodiscovery). It also [discovers logs](/docs/logs/discovery/intro/) you can ship to Sematext and monitor.
+[supported integrations](/docs/monitoring/autodiscovery/#which-integrations-allow-autodiscovery). It also [discovers logs](/docs/logs/discovery/intro/) you can ship to Sematext and monitor. To visualize discovered services and their connections, see [Network Map](/docs/network-map/services-view/).
 
 The discovered services and logs are displayed under `Fleet & Discovery > Discovery > Services`.  From there, one can set up both monitoring and log shipping via the UI without any additional installation or configuration.  Moreover, this is where auto-monitoring of supported integrations can be enabled, allowing Sematext Agent to automatically start monitoring newly discovered instances of the service for which you've set up monitoring. For example, if you have set up monitoring for Elasticsearch and enabled automatic monitoring then any new Elasticsearch nodes that are added to the cluster will automatically get monitored.
 
diff --git a/docs/monitoring/infrastructure.md b/docs/monitoring/infrastructure.md
index 52337482f..867a6bf1e 100644
--- a/docs/monitoring/infrastructure.md
+++ b/docs/monitoring/infrastructure.md
@@ -10,6 +10,8 @@ Sematext Infrastructure Monitoring provides complete insight into your infrastru
 - [inventory](/docs/monitoring/inventory/)
 - [events](/docs/events/), etc.
 
+For a visual topology of your infrastructure showing service connections and dependencies, see [Network Map](/docs/network-map/).
+
 For application and service monitoring, make sure to check our [dedicated guide](/docs/monitoring/service-monitoring/).
 
 The centerpiece is an Infra App which acts as a container for all data about your infrastructure. As with other App types, you can create as many Infra Apps under your account as you wish.
@@ -76,3 +78,4 @@ Infrastructure Monitoring provides:
 - [Kubernetes](/docs/agents/sematext-agent/kubernetes/metrics/) metrics and details
 - [Inventory](/docs/monitoring/inventory)
 - [Processes details and metrics](/docs/monitoring/processes)
+- [Network Map](/docs/network-map/) - Visualize your infrastructure topology and service connections
diff --git a/docs/monitoring/kubernetes.md b/docs/monitoring/kubernetes.md
index 32723127a..d2d28a269 100644
--- a/docs/monitoring/kubernetes.md
+++ b/docs/monitoring/kubernetes.md
@@ -5,4 +5,6 @@ Monitor Kubernetes clusters with a lightweight [Agent](/docs/agents/sematext-age
 
 ![Infra Kubernetes metrics](/docs/images/monitoring/infra-kubernetes-metrics.gif)
 
-For more info, check out our [Kubernetes Monitoring](/docs/integration/kubernetes/) integration that comes pre-loaded with every Infra App.
\ No newline at end of file
+For more info, check out our [Kubernetes Monitoring](/docs/integration/kubernetes/) integration that comes pre-loaded with every Infra App.
+
+For a visual topology of your Kubernetes clusters with drill-down from clusters to nodes, pods, containers, and processes, see [Network Map](/docs/network-map/infrastructure-view/).
\ No newline at end of file
diff --git a/docs/monitoring/network-map.md b/docs/monitoring/network-map.md
deleted file mode 100644
index a6699ec20..000000000
--- a/docs/monitoring/network-map.md
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Network Map
-description: Use NetMap to visualize the network topology and to discover and collect various data information on your hosts
-
-You can visualize the network topology of a system monitored by Sematext. The Sematext Agent
-can discover hosts and collect information about communication between
-them, such as the amount of received/transmitted data on each port. In
-order to build the Network Map the Sematext Monitoring Agent needs to be
-started on each host in the system. This can be done by setting `netmon.enabled` property to `true` in
-`/opt/spm/properties/st-agent.yml`. This property is disabled by default.
-
-The following properties can be changed:
-
-  - **netmon.interfaces** (default value: **eth0,eth1**) - the
-    list of network interfaces that will be used for packets capture.
-
-Sematext Agent needs to be restarted after any `st-agent.yml`changes:
-
-``` bash
-sudo service sematext-agent restart
-```
diff --git a/docs/network-map/filtering-search.md b/docs/network-map/filtering-search.md
new file mode 100644
index 000000000..76931da90
--- /dev/null
+++ b/docs/network-map/filtering-search.md
@@ -0,0 +1,104 @@
+title: Network Map Filtering & Search
+description: Find and filter specific services, infrastructure, and connections in Network Map.
+
+When you're managing dozens or hundreds of services, you need ways to focus on what matters. Network Map provides powerful filtering and search capabilities that help you cut through the noise and find exactly what you're looking for.
+
+![Services Filters Panel](../images/network-map/network-map-filters.png)
+
+## Finding Services with Search
+
+The search bar at the top of Network Map lets you quickly find specific services, nodes, pods, containers, processes, or hosts by name. Just start typing and matching elements are highlighted on the map.
+
+## Quick Filters for Common Problems
+
+Click the Filters button to open the Services Filters panel. At the top, you'll find Quick Filters - pre-configured filters based on your [threshold settings](/docs/network-map/thresholds/) that highlight common problem areas:
+
+**High Network** (>10MB/s) shows services with high network I/O. Use this to find services that might be bandwidth-constrained or experiencing unusual traffic.
+
+**High Disk I/O** (>70MB/s) reveals services with elevated disk activity. This helps identify storage bottlenecks or services that might benefit from caching.
+
+**High CPU** (>70% usage) filters to services consuming significant CPU. When your cluster is running hot, this immediately shows you where the bottleneck might be.
+
+**High Memory** (>80% usage) displays services approaching their memory limits. Catching these early helps prevent OOM kills and service disruptions.
+
+These quick filters are especially useful during incident response - instead of scanning the entire map, click "High CPU" to immediately see which services are struggling. The threshold values shown are defined in your [Threshold Settings](/docs/network-map/thresholds/).
+
+## Filtering by Environment
+
+The Environment & Infrastructure section lets you focus on specific parts of your infrastructure:
+
+Use the **Environment Type** checkboxes to filter by **Kubernetes** or **Bare-Metal** (standalone hosts - VMs, cloud instances like EC2, or physical servers). Each option displays a count of matching services, so you know how many elements will appear after filtering. You can select both to see your entire infrastructure, or focus on just one environment type.
+
+## Filtering by Service Type
+
+The **Service Types** section lets you filter by specific technologies. Use the checkboxes to select one or more service types from the paginated list:
+
+Looking for database issues? Select MySQL, PostgreSQL, or MongoDB to show only your database services. Troubleshooting messaging? Filter to Kafka and RabbitMQ. Investigating web traffic? Select Nginx and Apache.
+
+The list shows counts next to each service type (like "2 services"), helping you understand your infrastructure composition at a glance. Use the search box to quickly find a specific service type, or use the pagination controls to browse through all available types.
+
+## Filtering by Performance Metrics
+
+The **Performance & Metrics** section provides sliders to filter based on resource consumption:
+
+- **Network Traffic Rate (MB/s)** - Filter by network traffic volume to find your busiest services or investigate bandwidth issues
+- **Disk I/O Rate (MB/s)** - Filter by disk throughput to identify I/O-intensive services
+- **Connection Count** - Filter by the number of active connections to find services with many connections
+
+These sliders work as minimum thresholds - services above your selected value appear on the map.
+
+## Color Coding Options
+
+The "Color By" dropdown in the top-right corner controls how services and connections are visually represented:
+
+![Color By Options](../images/network-map/network-map-color-by.png)
+
+**Nodes** (service cards and infrastructure elements):
+
+- Network I/O
+- CPU Usage
+- Memory Usage
+- Disk I/O
+
+**Edges** (connection lines):
+
+- Traffic Volume
+- Connection Health
+
+Choose the metric most relevant to your current investigation. Traffic volume helps identify your busiest connections, while connection health highlights latency or reliability issues.
+
+The color scale uses green for healthy values (below your warning threshold), yellow for warning levels (between warning and critical), and red for critical values (above your critical threshold). Gray indicates no data is available.
+
+This color coding works with your [threshold configuration](/docs/network-map/thresholds/), so you can customize what "healthy" and "critical" mean for your environment.
+
+## Combining Filters
+
+Filters combine to narrow your view progressively. For example, you might:
+
+1. Select "Kubernetes" to focus on containerized services
+2. Filter to "PostgreSQL" service type to see only your databases
+3. Apply the "High CPU" quick filter to find which databases are working hardest
+
+The map updates immediately as you apply each filter, showing you only the services that match all your criteria.
+
+## Clearing Filters
+
+To reset your view, click "Clear All" in the filters panel or close the panel to return to showing all services. Individual filter sections also have their own clear options if you want to remove just one filter while keeping others.
+
+## Practical Examples
+
+**During an incident**: Open Quick Filters and click "High CPU" and "High Memory" to immediately see which services are resource-constrained. This is much faster than scanning the entire map.
+
+**Capacity planning**: Filter by service type to see all instances of a particular technology. Examine their resource usage to determine if you need to scale.
+
+**Investigating a namespace**: Use search to find services in a specific namespace, or filter by Kubernetes and then examine the namespace tags on each service.
+
+**Finding connection issues**: Color edges by Connection Health, then look for red lines indicating problematic connections. Click on them to see latency and error details.
+
+**Cost optimization**: Filter by low CPU and memory usage to find over-provisioned services that could be downsized. Look for services with minimal traffic that might be candidates for consolidation or removal. Identify redundant services running the same workload across multiple instances when fewer would suffice.
+
+## Next Steps
+
+- [Thresholds](/docs/network-map/thresholds/) to customize what "High CPU" and other quick filters mean for your environment
+- [Services View](/docs/network-map/services-view/) to understand the tier-based service layout
+- [Infrastructure View](/docs/network-map/infrastructure-view/) to drill down into Kubernetes and standalone host infrastructure
diff --git a/docs/network-map/getting-started.md b/docs/network-map/getting-started.md
new file mode 100644
index 000000000..012ea18be
--- /dev/null
+++ b/docs/network-map/getting-started.md
@@ -0,0 +1,81 @@
+title: Getting Started with Network Map
+description: Learn the prerequisites and how to enable Network Map for your infrastructure.
+
+Getting Network Map up and running takes just a few minutes if you already have Sematext Infra Monitoring in place. If you're new to Sematext, this guide walks you through everything you need.
+
+## What You Need
+
+Network Map requires two things:
+
+**An [Infra App](/docs/monitoring/infrastructure/)** to collect and store your infrastructure data. If you're already using Sematext for infrastructure monitoring, you have this. If not, you'll create one as part of the setup process.
+
+**[Sematext Agent](/docs/agents/sematext-agent/installation/)** installed on the hosts you want to monitor. The agent collects eBPF-based network connection data that powers Network Map's topology visualization. You need version 4.1.x or later.
+
+For best results, your hosts should be running **Linux kernel 5.8 or later**. Older kernels (4.15+) work but with some limitations. Check your kernel version with `uname -r`.
+
+## Enabling Network Map
+
+Navigate to Network Map in the Sematext Cloud sidebar. What you see next depends on your current setup:
+
+### If You Don't Have an Infra App
+
+![No Infra App](../images/network-map/network-map-enable-no-infra-app.png)
+
+You'll be prompted to create an Infra App first. Click "Create New Infra App" to create one, give it a name (like "Production Infrastructure" or "Staging Environment"), and you're set.
+
+Each Infra App typically represents one environment. Many teams have separate Infra Apps for production, staging, and development.
+
+### If You Have an Infra App But No Agents
+
+You'll see instructions to install [Sematext Agent](/docs/agents/sematext-agent/installation/). The installation is straightforward - you'll get a command to run on each host that includes your Infra App token.
+
+For Kubernetes environments, you'll deploy the agent as a DaemonSet so it runs on every node automatically.
+
+### If Everything Is Ready
+
+When you have an Infra App and agents installed, you'll see a summary of your infrastructure showing the number of hosts, Kubernetes clusters, pods, and containers that Network Map will monitor. If you've already enabled Network Map, you'll skip this screen and see your data directly.
+
+![Network Map Enable](../images/network-map/network-map-enable-ready.png)
+
+Click the Enable button to activate Network Map. There's no need to configure anything on your agents - the backend automatically enables Network Map data collection when you enable the feature. Your agents will start sending topology data right away.
+
+## What Happens After Enabling
+
+Once enabled, here's what to expect:
+
+**Data collection begins immediately.** The Sematext Agent starts observing network connections and sending topology data to Sematext Cloud.
+
+**Initial topology appears within minutes.** You'll see your first services and connections show up in Network Map. The visualization builds as the agent observes more connections.
+
+**The map becomes more complete over time.** Services that haven't made network connections yet won't appear until they do. As your infrastructure communicates, Network Map captures more of the topology.
+
+**No restart required.** Your agents don't need to restart when you enable Network Map. The feature activates and deactivates dynamically.
+
+## Verifying It's Working
+
+After a few minutes, you should see:
+
+- Service nodes appearing on the map
+- Connection lines between services showing protocols and traffic
+- Your Kubernetes clusters and nodes (if applicable) in the Infrastructure view
+
+If nothing appears after 10 minutes, check the [Troubleshooting](/docs/network-map/troubleshooting/) guide.
+
+## Using the Quick Guide
+
+Click the **Quick Guide** button in the top-right corner of Network Map to see a visual legend explaining the interface. The Quick Guide shows you what the different node colors mean (green for healthy, yellow for warning, red for critical), how connection lines are colored based on traffic volume and health, and what controls are available. It's a handy reference while you're learning the interface.
+
+![Quick Guide](../images/network-map/network-map-quick-guide.png)
+
+## Pricing
+
+For Network Map pricing details, visit [sematext.com/pricing](https://sematext.com/pricing).
+
+## Next Steps
+
+Once Network Map is running:
+
+- [Services View](/docs/network-map/services-view/) - Explore your services organized by tier
+- [Infrastructure View](/docs/network-map/infrastructure-view/) - Drill down into Kubernetes clusters and standalone hosts
+- [Filtering & Search](/docs/network-map/filtering-search/) - Learn to find and filter specific services
+- [Thresholds](/docs/network-map/thresholds/) - Customize warning and critical levels for your environment
diff --git a/docs/network-map/index.md b/docs/network-map/index.md
new file mode 100644
index 000000000..4453e49cd
--- /dev/null
+++ b/docs/network-map/index.md
@@ -0,0 +1,70 @@
+title: Network Map
+description: Visualize your entire infrastructure topology in real-time with eBPF-powered network insights. See Kubernetes clusters, standalone hosts, databases, containers, processes, and communication patterns.
+
+Network Map gives you a real-time, visual representation of your entire infrastructure topology. Using eBPF-powered network insights collected by the Sematext Agent, you can see how your services, pods, containers, and processes communicate across Kubernetes clusters and standalone hosts.
+
+Instead of mentally piecing together your infrastructure from logs, metrics, and configuration files, Network Map shows you the actual connections happening right now. When something breaks, you can immediately see which services are affected and trace the problem to its source.
+
+![Network Map Services View](../images/network-map/network-map-services-view.png)
+
+## Why Use Network Map?
+
+Traditional monitoring tells you that a service is slow or throwing errors. Network Map shows you *why* and exactly *where* - maybe a downstream database is overloaded, or traffic is being routed through an unexpected path, or a new service deployment broke a critical connection.
+
+With Network Map, you can:
+
+**Understand your infrastructure at a glance.** See all your services, how they connect, and what protocols they use. No more guessing which services talk to which databases, or wondering if that new microservice is actually being called.
+
+**Troubleshoot faster.** When an alert fires, open Network Map to immediately see the affected service and all its dependencies. Click on connections to see traffic volume, latency, and protocol details. Identify bottlenecks by spotting services with high CPU or memory usage - they're colored red so you can't miss them.
+
+**Navigate complex Kubernetes environments.** Drill down from cluster to node to pod to container to process. See inter-node traffic, identify which pods are communicating across nodes, and understand your namespace topology.
+
+**Discover your services automatically.** Network Map detects [over 100 service types](/docs/network-map/supported-services/) including databases, caches, message queues, and web servers. You don't need to configure anything - it recognizes PostgreSQL, Redis, Kafka, Nginx, and many more from their network signatures.
+
+**Reduce infrastructure costs.** Identify over-provisioned services that are consuming resources but are barely being used. Spot redundant connections, find services that could be consolidated, and discover unused infrastructure. When you can see exactly what's running and how it's being used, you can make informed decisions about where to cut costs without impacting performance.
+
+**Replace outdated architecture diagrams.** Static diagrams get stale the moment they're created, and nobody wants to maintain them. Network Map shows your actual architecture as it exists right now - no more onboarding new engineers with outdated documentation or hunting for the "latest" version of a diagram that doesn't exist.
+
+## Two Ways to View Your Infrastructure
+
+Network Map offers two complementary views, accessible via tabs at the top of the interface:
+
+The [Services View](/docs/network-map/services-view/) shows your business applications and their connections. This is ideal for understanding service dependencies and troubleshooting application-level issues. You can see at a glance which services connect to your databases, how traffic flows between components, and where bottlenecks occur.
+
+The [Infrastructure View](/docs/network-map/infrastructure-view/) shows your physical and virtual infrastructure hierarchy. For Kubernetes, you can drill down from clusters to nodes to pods to containers to processes. For standalone hosts, you see your servers and the services running on them. This view is perfect for capacity planning, identifying noisy neighbors, and understanding resource distribution.
+
+## Use Cases
+
+Beyond day-to-day monitoring, Network Map helps with scenarios that are hard to tackle with traditional tools:
+
+**Discover unknown dependencies.** "I didn't know service X talks to database Y" - these surprises often surface during incidents. Network Map shows all connections, including ones that weren't in the original architecture design or that were added without updating documentation.
+
+**Detect suspicious connections.** See which external IPs and destinations your services communicate with. Spot unexpected outbound connections that might indicate compromised services or misconfigured applications reaching unintended endpoints.
+
+**Identify data exfiltration.** Unusual outbound data volumes from databases or internal services can indicate a security breach. Network Map shows traffic volumes on every connection, making abnormal patterns visible.
+
+**Find rogue processes.** Detect unexpected processes making network calls. Malware, cryptocurrency miners, or unauthorized applications often reveal themselves through their network activity.
+
+**Uncover cross-region cost leakage.** Cloud providers charge for cross-region and cross-zone traffic. Network Map reveals connections you didn't know existed - like a US service regularly calling an EU database - so you can address unexpected bandwidth costs.
+
+**Audit third-party integrations.** See exactly which external services your infrastructure communicates with. Useful for security reviews, compliance audits, and understanding your actual attack surface.
+
+## Getting Started
+
+To use Network Map, you need:
+
+1. At least one [Infra App](/docs/monitoring/infrastructure/) created in Sematext Cloud
+2. [Sematext Agent](/docs/agents/sematext-agent/) installed on your hosts (version 4.1.x or later)
+
+Once enabled, Network Map starts collecting data immediately. Within a few minutes, you'll see your first topology visualization.
+
+See [Getting Started](/docs/network-map/getting-started/) for detailed setup instructions.
+
+## Learn More
+
+- [Getting Started](/docs/network-map/getting-started/) - Prerequisites and enabling Network Map
+- [Services View](/docs/network-map/services-view/) - Understand service dependencies and connections
+- [Infrastructure View](/docs/network-map/infrastructure-view/) - Navigate Kubernetes and standalone host infrastructure
+- [Filtering & Search](/docs/network-map/filtering-search/) - Find specific services and focus on what matters
+- [Thresholds](/docs/network-map/thresholds/) - Customize warning and critical levels for your environment
+- [Troubleshooting](/docs/network-map/troubleshooting/) - Common issues and solutions
diff --git a/docs/network-map/infrastructure-view.md b/docs/network-map/infrastructure-view.md
new file mode 100644
index 000000000..093fbf3f3
--- /dev/null
+++ b/docs/network-map/infrastructure-view.md
@@ -0,0 +1,92 @@
+title: Infrastructure View
+description: Navigate your Kubernetes clusters and standalone hosts with drill-down capabilities.
+
+The Infrastructure View shows your physical and virtual infrastructure in a hierarchical layout. For Kubernetes environments, you can drill down from clusters to nodes to pods to containers to processes. For standalone hosts, you see your servers and what's running on them.
+
+This view is essential for understanding resource distribution, identifying noisy neighbors, troubleshooting node-level issues, and capacity planning.
+
+![Kubernetes Clusters View](../images/network-map/network-map-k8s-clusters.png)
+
+## Navigating Kubernetes Infrastructure
+
+When you switch to the Infrastructure tab and select Kubernetes, you start at the cluster level. From here, you can drill down through five levels of hierarchy:
+
+**Clusters** show all your Kubernetes clusters. Each cluster card displays the cluster name, namespaces, CPU and memory utilization, and the count of nodes, pods, and containers. Click on a cluster to see its nodes.
+
+![Cluster Details](../images/network-map/network-map-k8s-cluster-details.png)
+
+Click on a cluster to open the Cluster Details panel, which shows the cluster name, environment, total resources (nodes, pods, containers), namespaces, and resource utilization bars for CPU, memory, and network I/O.
+
+**Nodes** display the worker nodes within the selected cluster. You can see which nodes are running hot (high CPU or memory), how many pods each node is running, and the intra-cluster traffic flowing between nodes.
+
+![Nodes View](../images/network-map/network-map-k8s-nodes.png)
+
+The connections between nodes show intra-cluster traffic with volume labels like "Intra-cluster (1.2 MB)". This helps you identify unexpected cross-node communication patterns.
+
+![Node Details](../images/network-map/network-map-k8s-node-details.png)
+
+Click on a node to see the Node Details panel with resource utilization (CPU cores, memory, disk, network I/O) and a list of running pods on that node.
+
+**Pods** appear when you click into a node. Each pod card shows its name, namespace, CPU and memory usage, and container count.
+
+![Pods View](../images/network-map/network-map-k8s-pods.png)
+
+**Containers** are visible when you drill into a pod. You can see each container's image name, runtime (like Docker), and resource usage. This is useful for multi-container pods where you need to identify which specific container is causing issues.
+
+![Containers View](../images/network-map/network-map-k8s-containers.png)
+
+![Container Details](../images/network-map/network-map-k8s-container-details.png)
+
+Click on a container to see the Container Details panel with the container name, image, runtime, container ID, and resource utilization.
+
+**Processes** are the deepest level. When viewing a container, you can see all running processes with their CPU usage, memory consumption, PID, and TGID. This helps you identify exactly what's executing inside each container and which processes are consuming resources.
+
+A breadcrumb trail at the top tracks your navigation path. For example: `K8s Clusters → prod-us-west → k8s-node-01 → frontend-nginx → Containers`. Click any level in the breadcrumb to jump back up the hierarchy.
+
+## Understanding Intra-Cluster Traffic
+
+At the node level, you'll see connections between nodes with traffic volume labels like "Intra-cluster (1.2 MB)". This visualization helps you:
+
+- Identify pods that communicate heavily across nodes, which might benefit from co-location
+- Spot unexpected traffic patterns that could indicate misconfiguration
+- Understand the network load between nodes for capacity planning
+
+The connections are color-coded by traffic volume, so high-traffic connections stand out immediately.
+
+## Standalone Hosts
+
+Toggle to the "Bare-Metal" tab to see your non-Kubernetes infrastructure. This view shows your standalone hosts (VMs or physical servers) as cards on the canvas.
+
+![Bare-Metal Hosts View](../images/network-map/network-map-bare-metal-hosts.png)
+
+Each host card displays the hostname, a "VM" badge, the primary service detected running on that host (like MySQL or Apache), and current CPU and memory utilization.
+
+Click on any host to open the Host Details panel, which shows the node ID, environment, and resource utilization bars for CPU, memory, disk, and network I/O.
+
+This view is appropriate for traditional infrastructure that isn't containerized, or for mixed environments where you have both Kubernetes and standalone servers.
+
+## Practical Use Cases
+
+**Troubleshooting a slow service**: Start in the Services View to identify the slow service, then switch to Infrastructure View. Drill down to the pod level to check resource usage. If the pod looks fine, check the node - maybe it's overloaded or experiencing network issues with other nodes.
+
+**Investigating a node problem**: If you receive an alert about a node, go directly to Infrastructure View, find the node, and examine its pods. The details panel shows you which pods are consuming the most resources, helping you identify whether one workload is monopolizing the node.
+
+**Capacity planning**: Use the cluster and node views to understand resource distribution. Identify nodes that are consistently running hot and pods that might need resource limit adjustments.
+
+**Debugging container issues**: When pod-level investigation isn't enough, drill down to the container level. The Container Details panel shows you which processes are running inside each container, helping you verify the right workloads are executing.
+
+**Reducing infrastructure costs**: Identify nodes with low utilization that could be candidates for consolidation. Find pods consuming minimal resources that might be over-provisioned. Spot idle containers that could be shut down. When you can see actual resource usage across your entire infrastructure, you can make data-driven decisions about rightsizing and eliminate waste.
+
+## Navigation Controls
+
+The minimap in the bottom-right corner shows an overview of the entire topology, helping you understand where you are in relation to the full map.
+
+Zoom controls let you adjust the detail level. When zoomed out, you see more elements but less detail per element. Zoom in to focus on a smaller area with full information.
+
+Use the zoom indicator to see your current zoom level, which affects how much information appears on each card.
+
+## Next Steps
+
+- [Services View](/docs/network-map/services-view/) to understand service-level dependencies and connections
+- [Filtering & Search](/docs/network-map/filtering-search/) to find specific pods, filter by namespace, or focus on resource-heavy workloads
+- [Thresholds](/docs/network-map/thresholds/) to set appropriate warning and critical levels for your infrastructure
diff --git a/docs/network-map/services-view.md b/docs/network-map/services-view.md
new file mode 100644
index 000000000..5c5fb7a44
--- /dev/null
+++ b/docs/network-map/services-view.md
@@ -0,0 +1,96 @@
+title: Services View
+description: Visualize your services and their connections with real-time metrics and network insights.
+
+The Services View shows your business applications and their connections. You can see how services communicate, identify which databases and caches your applications depend on, and trace request flows through your infrastructure.
+
+![Services View](../images/network-map/network-map-services-view.png)
+
+## Understanding the Layout
+
+Services are displayed as cards on the canvas, with connection lines showing how they communicate. The layout helps you visualize your application topology - you can see which services connect to databases, which ones communicate with message queues, and how traffic flows between components.
+
+Each service card shows at a glance whether it's running in Kubernetes (marked with a "k8s" badge) or on a standalone host (marked with "VM"). The connections between services are labeled with the protocol and traffic volume, making it easy to identify your busiest communication paths.
+
+## Reading the Service Cards
+
+Each service card tells you everything you need to know at a glance:
+
+The service name and icon tell you what type of service it is. A badge shows whether it's running in Kubernetes ("k8s") or on a standalone host ("VM"). You'll also see tags indicating the service type (like "Data" for databases or "Application" for your business services), the workload type (Deployment, StatefulSet, etc.), and how many active connections the service has.
+
+The CPU and memory percentages show current resource usage. These numbers change color based on your [threshold settings](/docs/network-map/thresholds/) - green means healthy, yellow means warning, red means critical. When a service turns red, you know immediately where to focus your attention.
+
+For Kubernetes services, you'll also see the namespace and the host where the service is running, giving you context about where the service lives in your infrastructure.
+
+## Understanding Connections
+
+The lines between services represent actual network connections. Each line shows:
+
+The protocol being used - HTTP, PostgreSQL, MongoDB, Kafka, or any of the [dozens of protocols](/docs/network-map/supported-services/#supported-protocols) Network Map detects. The traffic volume appears as a label on the line, like "HTTP (1.2MB)", so you can see which connections are handling the most data.
+
+Connection lines are color-coded. Green connections are healthy. Yellow indicates elevated latency or traffic approaching your thresholds. Red means the connection is experiencing problems - high latency, errors, or traffic beyond your critical threshold.
+
+The lines animate to show active traffic flow, and a red line immediately draws your eye to a problematic connection.
+
+## Investigating a Service
+
+Click on any service to open its details panel:
+
+![Service Details Panel](../images/network-map/network-map-service-details.png)
+
+The **Service Overview** section shows where the service is running - the host name and IP address. This helps you quickly identify the physical or virtual location of the service.
+
+The **Service Metrics** section displays real-time resource utilization with visual bars for CPU, memory, network I/O, and disk I/O. The bars are color-coded based on your [threshold settings](/docs/network-map/thresholds/), so you can immediately see if a service is resource-constrained.
+
+The **Network Connections** section lists every connection to and from this service. You can filter to show All, Incoming, or Outgoing connections, and sort by Traffic Volume, Service Name, or Protocol. Each connection entry shows the direction (an arrow indicates whether this service is the client or server), the connected service name, the protocol being used, and the traffic volume.
+
+The **Process Details** section at the bottom shows the underlying process information - the detected service type, host, process ID (TGID), listening ports, and the full command line. This is invaluable for debugging configuration issues or identifying exactly what's running.
+
+## Investigating a Connection
+
+Click on any connection line to open the Connection Details panel:
+
+![Connection Details Panel](../images/network-map/network-map-connection-details.png)
+
+The **Traffic Metrics** section shows the total data transferred over this connection and the connection status (like ESTABLISHED for active connections).
+
+The **Connection Stats** section displays the connection duration and retransmission count. High retransmissions can indicate network issues or congestion.
+
+The **Protocol Details** section shows the detected protocol (HTTP, PostgreSQL, MongoDB, etc.), the network layer (Application), the port number, and any protocol-specific features.
+
+The **Connection Properties** section describes the connection attributes - whether it's bidirectional or unidirectional, peer-to-peer or client-server, and other characteristics that help you understand the nature of the communication.
+
+This helps you understand not just *that* services are connected, but *how* they're communicating.
+
+## Zoom Levels
+
+Network Map adapts its display based on your zoom level:
+
+When zoomed out, you see the big picture - service names, icons, and colored health indicators. This is useful for getting an overview and spotting problem areas.
+
+As you zoom in, more details appear: metrics, connection counts, namespace information, and pod counts. At the highest zoom levels, you see everything - full service cards with all available information.
+
+Use the zoom controls in the bottom-left corner, or scroll to zoom. The zoom indicator shows your current level.
+
+## Automatic Service Detection
+
+Network Map automatically recognizes [over 100 service types](/docs/network-map/supported-services/) without any configuration. It identifies services based on container images, process names, network signatures, and Kubernetes metadata.
+
+Supported services include:
+
+- Databases like PostgreSQL, MySQL, MongoDB, Cassandra, and Elasticsearch
+- Caches like Redis and Memcached
+- Message queues like Kafka, RabbitMQ, and NATS
+- Web servers like Nginx, Apache, and Caddy
+- Proxies and gateways like HAProxy, Traefik, Kong, and Envoy
+- Monitoring systems like Prometheus and Grafana
+- Runtimes for Java, Node.js, Python, Go, .NET, and more
+
+When Network Map detects a service, it shows the appropriate icon and applies type-specific intelligence for protocol detection and visualization.
+
+## Next Steps
+
+Once you're comfortable with the Services View, explore:
+
+- [Infrastructure View](/docs/network-map/infrastructure-view/) to drill down into your Kubernetes clusters and standalone hosts
+- [Filtering & Search](/docs/network-map/filtering-search/) to focus on specific services or find high-resource consumers
+- [Thresholds](/docs/network-map/thresholds/) to customize the warning and critical levels for your environment
diff --git a/docs/network-map/supported-services.md b/docs/network-map/supported-services.md
new file mode 100644
index 000000000..ff47b0901
--- /dev/null
+++ b/docs/network-map/supported-services.md
@@ -0,0 +1,306 @@
+title: Supported Services
+description: Complete list of services automatically detected by Network Map.
+
+Network Map automatically detects and identifies over 100 service types across your infrastructure. Detection uses multiple signals including container images, process names, ports, and Kubernetes metadata.
+
+## Databases
+
+### SQL Databases
+
+| Service | Default Ports |
+|---------|---------------|
+| PostgreSQL | 5432 |
+| MySQL | 3306 |
+| MariaDB | 3306 |
+| Percona | 3306 |
+| Oracle | 1521 |
+| SQL Server | 1433 |
+| CockroachDB | 26257 |
+| TimescaleDB | 5432 |
+
+### NoSQL Databases
+
+| Service | Default Ports |
+|---------|---------------|
+| MongoDB | 27017 |
+| Cassandra | 9042, 7000 |
+| ScyllaDB | 9042 |
+| CouchDB | 5984 |
+| Couchbase | 8091 |
+| Neo4j | 7474, 7687 |
+| ArangoDB | 8529 |
+| RethinkDB | 8080, 28015 |
+| OrientDB | 2424 |
+
+### Key-Value & Cache
+
+| Service | Default Ports |
+|---------|---------------|
+| Redis | 6379 |
+| Memcached | 11211 |
+| Hazelcast | 5701 |
+| etcd | 2379, 2380 |
+
+### Time Series Databases
+
+| Service | Default Ports |
+|---------|---------------|
+| InfluxDB | 8086 |
+| Prometheus | 9090 |
+| VictoriaMetrics | 8428 |
+
+## Search & Analytics
+
+| Service | Default Ports |
+|---------|---------------|
+| Elasticsearch | 9200, 9300 |
+| OpenSearch | 9200, 9600 |
+| Apache Solr | 8983 |
+| Sphinx | 9312 |
+| Manticore | 9306 |
+| Meilisearch | 7700 |
+| Typesense | 8108 |
+
+## Web Servers & Proxies
+
+| Service | Default Ports |
+|---------|---------------|
+| Nginx | 80, 443 |
+| Apache (httpd) | 80, 443 |
+| Caddy | 80, 443 |
+| Traefik | 80, 443, 8080 |
+| HAProxy | 80, 443 |
+| Envoy | 8001, 9901 |
+| Kong | 8000, 8443 |
+| Ambassador | 8080 |
+| Contour | 8001 |
+
+## Service Mesh
+
+| Service | Default Ports |
+|---------|---------------|
+| Istio Proxy | 15001, 15006 |
+| Linkerd | 8086 |
+| Consul | 8500, 8600 |
+
+## Message Queues & Streaming
+
+| Service | Default Ports |
+|---------|---------------|
+| Apache Kafka | 9092 |
+| ZooKeeper | 2181 |
+| RabbitMQ | 5672, 15672 |
+| ActiveMQ | 61616, 8161 |
+| Artemis | 61616 |
+| NATS | 4222 |
+| Apache Pulsar | 6650, 8080 |
+| Redpanda | 9092 |
+| EventStore | 2113 |
+| NSQ | 4150, 4161 |
+
+## Monitoring & Observability
+
+| Service | Default Ports |
+|---------|---------------|
+| Grafana | 3000 |
+| Jaeger | 14268, 16686 |
+| Zipkin | 9411 |
+| Kibana | 5601 |
+| OpenSearch Dashboards | 5601 |
+| OpenTelemetry Collector | 4317, 4318 |
+| Datadog Agent | - |
+| New Relic Agent | - |
+
+## Logging
+
+| Service | Default Ports |
+|---------|---------------|
+| Splunk | 8000, 8089 |
+| Fluentd | 24224 |
+| Fluent Bit | 24224 |
+| Logstash | 5044, 9600 |
+| Filebeat | - |
+| Metricbeat | - |
+| Telegraf | - |
+
+## Application Servers
+
+### Java Application Servers
+
+| Service | Default Ports |
+|---------|---------------|
+| Apache Tomcat | 8080, 8443 |
+| Jetty | 8080 |
+| WildFly (JBoss) | 8080, 9990 |
+| WebSphere | 9060 |
+| WebLogic | 7001 |
+| Spring Boot | 8080 |
+
+### Application Runtimes
+
+| Service | Detected From |
+|---------|---------------|
+| Java applications | Process, container image |
+| Node.js | Process, container image |
+| Python | Process, container image |
+| Go | Container image |
+| Ruby | Process, container image |
+| PHP (PHP-FPM) | Process, container image |
+| .NET | Process, container image |
+| Rust | Container image |
+| Scala | Container image |
+
+## Container & Orchestration
+
+| Service | Default Ports |
+|---------|---------------|
+| Kubernetes | 6443 |
+| Docker | 2375, 2376 |
+| containerd | - |
+| Podman | - |
+| CRI-O | - |
+| OpenShift | 8443 |
+| Rancher | 443 |
+| Nomad | 4646 |
+
+## CI/CD & DevOps
+
+| Service | Default Ports |
+|---------|---------------|
+| GitLab | 80, 443 |
+| Jenkins | 8080 |
+| SonarQube | 9000 |
+| Nexus | 8081 |
+| Artifactory | 8081 |
+
+## Security & Identity
+
+| Service | Default Ports |
+|---------|---------------|
+| HashiCorp Vault | 8200 |
+| Keycloak | 8080 |
+| LDAP (OpenLDAP) | 389, 636 |
+
+## Storage
+
+| Service | Default Ports |
+|---------|---------------|
+| MinIO | 9000 |
+
+## Supported Protocols
+
+Network Map also detects the network protocol used in each connection. This helps you understand not just which services are communicating, but how they're communicating.
+
+### Web & API
+
+| Protocol | Default Ports |
+|----------|---------------|
+| HTTP | 80, 8080 |
+| HTTPS | 443, 8443 |
+
+### Database
+
+| Protocol | Default Ports |
+|----------|---------------|
+| MySQL | 3306 |
+| PostgreSQL | 5432 |
+| MongoDB | 27017 |
+| Redis | 6379 |
+| Cassandra | 9042 |
+
+### Messaging
+
+| Protocol | Default Ports |
+|----------|---------------|
+| Kafka | 9092 |
+| AMQP (RabbitMQ) | 5672 |
+| NATS | 4222 |
+
+### Search
+
+| Protocol | Default Ports |
+|----------|---------------|
+| Elasticsearch HTTP | 9200 |
+| Elasticsearch Transport | 9300 |
+
+### Monitoring
+
+| Protocol | Default Ports |
+|----------|---------------|
+| Prometheus | 9090 |
+| Grafana | 3000 |
+| InfluxDB | 8086 |
+
+### Container & Orchestration
+
+| Protocol | Default Ports |
+|----------|---------------|
+| Kubernetes API | 6443 |
+| Kubelet | 10250 |
+| Docker API | 2375, 2376 |
+| etcd | 2379 |
+
+### Service Mesh
+
+| Protocol | Default Ports |
+|----------|---------------|
+| Envoy Admin | 15000 |
+| Consul | 8500 |
+
+### Infrastructure
+
+| Protocol | Default Ports |
+|----------|---------------|
+| DNS | 53 |
+| SSH | 22 |
+| LDAP | 389, 636 |
+
+### Email
+
+| Protocol | Default Ports |
+|----------|---------------|
+| SMTP | 25, 465, 587 |
+| IMAP | 143, 993 |
+| POP3 | 110, 995 |
+
+### File Transfer
+
+| Protocol | Default Ports |
+|----------|---------------|
+| FTP | 21 |
+| TFTP | 69 |
+
+### Remote Access
+
+| Protocol | Default Ports |
+|----------|---------------|
+| RDP | 3389 |
+| VNC | 5900 |
+
+Connections on unrecognized ports appear with generic labels showing the port number.
+
+## Detection Methods
+
+Network Map uses multiple detection methods with varying confidence levels:
+
+| Method | Confidence | Description |
+|--------|------------|-------------|
+| Container image | High | Matches known service patterns in image names |
+| Process executable | High | Identifies services by process name (e.g., `nginx`, `postgres`) |
+| JVM analysis | Medium-High | Analyzes Java command lines, JAR names, and system properties |
+| Container labels | Medium | Reads Docker/Kubernetes labels like `app.kubernetes.io/name` |
+| Port analysis | Medium | Infers service type from well-known ports |
+| Kubernetes metadata | Medium | Extracts service names from pod names and labels |
+| Environment variables | Low-Medium | Checks for `SERVICE_NAME`, `APP_NAME`, etc. |
+
+When multiple detection methods match, the highest confidence result is used.
+
+## Unrecognized Services
+
+Services not matching any known patterns appear with generic names based on their process executable or container image. They still show up on the map with their connections and metrics - only the service icon and categorization differ.
+
+## Next Steps
+
+- [Services View](/docs/network-map/services-view/) to see how detected services are displayed
+- [Filtering & Search](/docs/network-map/filtering-search/) to filter by service type
+- [Troubleshooting](/docs/network-map/troubleshooting/) if services aren't being detected correctly
diff --git a/docs/network-map/thresholds.md b/docs/network-map/thresholds.md
new file mode 100644
index 000000000..e3d4dbd48
--- /dev/null
+++ b/docs/network-map/thresholds.md
@@ -0,0 +1,98 @@
+title: Threshold Configuration
+description: Customize warning and critical thresholds for Network Map visualizations.
+
+Thresholds determine when services and connections change color from green (healthy) to yellow (warning) to red (critical). By customizing these thresholds, you ensure that Network Map's visual indicators match your infrastructure's normal operating ranges.
+
+Every environment is different. A database server that normally runs at 70% CPU is healthy, while an API server at 70% might indicate a problem. Thresholds let you define what "normal" means for your specific infrastructure.
+
+![Edit Thresholds Dialog](../images/network-map/network-map-thresholds.png)
+
+## Accessing Threshold Settings
+
+Click the "Thresholds" button in the Network Map header to open the Edit Thresholds dialog. You'll see expandable sections for each metric type. Click on any section to expand it and configure the threshold values.
+
+## Understanding Threshold Levels
+
+Each metric has three color zones defined by two threshold values:
+
+**Healthy** (green) - Values below the warning threshold. This indicates normal operation.
+
+**Warning** (yellow) - Values between the warning and critical thresholds. This indicates elevated usage that you should be aware of but isn't yet critical.
+
+**Critical** (red) - Values above the critical threshold. This indicates a problem that needs attention.
+
+For example, with CPU thresholds set to Warning at 50% and Critical at 90%:
+
+- Below 50% CPU → Green (Healthy)
+- 50-90% CPU → Yellow (Warning)
+- Above 90% CPU → Red (Critical)
+
+A visual bar in each threshold section shows how these zones are distributed.
+
+## Configuring Each Metric
+
+### CPU Usage
+
+CPU thresholds are percentages. Set the Warning and Critical values based on what's normal for your environment.
+
+If your services normally run at higher CPU levels, increase these thresholds so you don't see constant warnings. If you want earlier alerts, lower them.
+
+Consider your workload patterns. Batch processing jobs might regularly spike to 100% CPU and that's fine. Web services running consistently above 80% might indicate capacity issues.
+
+### Memory Usage
+
+Memory thresholds are percentages. For services, Network Map shows RSS (Resident Set Size) - the actual physical memory allocated to the process. Watching for unexpected growth can help catch memory leaks early.
+
+For JVM-based services, heap usage patterns differ from RSS. A JVM might show high heap usage but be perfectly healthy if garbage collection is working well.
+
+### Network I/O
+
+Network I/O thresholds are in MB/s. These might need significant adjustment based on your infrastructure. A file server legitimately moves terabytes of data. A microservice might consider 10 MB/s unusually high.
+
+High network I/O isn't always bad - it might mean your service is busy doing its job. But unexpected network traffic spikes can indicate problems like runaway queries, cache misses, or attacks.
+
+### Disk I/O
+
+Disk I/O thresholds are in MB/s. Database servers and logging systems naturally have high disk I/O. Adjust these thresholds based on your storage tier's capabilities. An NVMe drive handles very different loads than a network-attached volume.
+
+Sustained high disk I/O can indicate database queries without proper indexes, logging verbosity issues, or storage subsystem problems.
+
+### Traffic Volume
+
+Traffic volume thresholds apply to connection edges. These thresholds color the lines between services. High traffic connections might indicate busy services or could suggest unexpected data flows. Lower thresholds help you spot unusual traffic patterns.
+
+### Connection Health
+
+Connection health thresholds are latency in milliseconds. These affect connection line colors based on response time. Adjust based on your latency expectations - internal microservices might expect sub-10ms responses, while external API calls might tolerate hundreds of milliseconds.
+
+## How Thresholds Affect the Interface
+
+Your threshold settings influence several parts of Network Map:
+
+**Node colors** change based on the metric you've selected in the "Color by" dropdown. If you're coloring by CPU and a service exceeds your CPU critical threshold, it turns red.
+
+**Connection colors** change based on traffic volume or connection health thresholds, depending on your edge coloring selection.
+
+**Quick Filters** use your thresholds. When you click "High CPU" in the filters panel, it shows services above your CPU warning threshold. Adjusting your thresholds changes what these filters show.
+
+**Detail panel indicators** show where current values fall relative to your thresholds. The visual bars in service details use green, yellow, and red sections based on your configuration.
+
+## Recommendations for Setting Thresholds
+
+Start with the defaults and adjust based on observation. Watch Network Map during normal operations for a day or two. If services are constantly yellow or red during normal operation, your thresholds are too low. If you never see warnings, they might be too high.
+
+Consider setting different mental expectations for different service types. Unfortunately, thresholds are global - you can't set different CPU thresholds for databases versus web servers. Choose values that minimize false alarms while still catching real problems.
+
+For critical services, consider more conservative thresholds. It's better to investigate a false alarm than to miss a real problem.
+
+Review your thresholds after infrastructure changes. If you upgrade to faster storage, your disk I/O thresholds might need adjustment. If you scale up your services, network thresholds might need to increase.
+
+## Saving Changes
+
+After configuring your thresholds, click the "Update Thresholds" button to apply your changes. The changes take effect immediately across all Network Map views.
+
+## Next Steps
+
+- [Filtering & Search](/docs/network-map/filtering-search/) to use Quick Filters based on your threshold settings
+- [Services View](/docs/network-map/services-view/) to see threshold-based coloring in action
+- [Infrastructure View](/docs/network-map/infrastructure-view/) to apply these thresholds to your Kubernetes and standalone host infrastructure
diff --git a/docs/network-map/troubleshooting.md b/docs/network-map/troubleshooting.md
new file mode 100644
index 000000000..9f3070f41
--- /dev/null
+++ b/docs/network-map/troubleshooting.md
@@ -0,0 +1,132 @@
+title: Troubleshooting Network Map
+description: Solutions for common Network Map issues and requirements.
+
+This guide helps you resolve common issues with Network Map and understand its requirements.
+
+## Requirements
+
+Network Map requires:
+
+**An Infra App** in your Sematext Cloud account. The Infra App collects infrastructure metrics and provides the foundation for Network Map's topology visualization. If you don't have one, create one at [Sematext Cloud US](https://apps.sematext.com/ui/infrastructure/create) or [Sematext Cloud EU](https://apps.eu.sematext.com/ui/infrastructure/create).
+
+**[Sematext Agent](/docs/agents/sematext-agent/installation/) version 4.1.x or later** installed on your hosts. The agent collects the eBPF-based network connection data that powers Network Map. Check your agent version with `sematext-agent --version`.
+
+**Linux kernel 5.8 or later** for optimal performance. Network Map uses eBPF with ring buffers, which requires kernel 5.8+. Older kernels (4.15+) work but with reduced performance and some limitations. Check your kernel version with `uname -r`.
+
+## Outdated Agents Warning
+
+![Outdated Agents Warning](../images/network-map/network-map-outdated-agents.png)
+
+If you see a warning like "Update 9 outdated Agents to see the full Network Map", some of your agents are running older versions that don't support all Network Map features.
+
+This typically happens when you've added Network Map to an environment where agents were installed before the feature was available, or when some hosts haven't received agent updates.
+
+To resolve this:
+
+1. Click the warning banner to see which hosts have outdated agents, or use [Fleet](/docs/fleet/) to view all your agents and their versions
+2. Update those agents to version 4.1.x or later
+3. The warning disappears once all agents are current
+
+Follow the [Sematext Agent update instructions](/docs/agents/sematext-agent/installation/) to upgrade your agents to the latest version.
+
+## No Data Showing
+
+If Network Map is enabled but shows no services or connections, work through these checks:
+
+**Verify the agent is running:**
+
+```bash
+systemctl status sematext-agent
+```
+
+If it's not running, start it with `sudo systemctl start sematext-agent`.
+
+**Check agent logs for errors:**
+
+```bash
+journalctl -u sematext-agent -f
+```
+
+Look for connection errors, authentication failures, or eBPF-related warnings.
+
+**Verify your Infra App token is configured correctly.** The agent needs a valid token to send data. Check your agent configuration and ensure the token matches an Infra App in your Sematext account. To find your Infra App token, go to the Monitoring page in [Sematext Cloud US](https://apps.sematext.com/ui/monitoring) or [Sematext Cloud EU](https://apps.eu.sematext.com/ui/monitoring), find your Infra App in the list, click the three dots in the Actions column, and select "App Settings". The token is displayed on that page.
+
+**Confirm Network Map is enabled.** Visit the Network Map page in Sematext Cloud and confirm it's enabled. If it shows options to enable, click to enable it.
+
+**Wait for data collection.** After enabling Network Map or installing a new agent, initially, data take a few minutes to appear. The agent needs time to observe network connections and send the data to Sematext.
+
+**Check kernel compatibility.** If you're running a kernel older than 4.15, eBPF features may not work. Check with `uname -r`.
+
+## Missing Services
+
+If some services you expect aren't appearing:
+
+**Give it time.** New services take a few minutes to appear after they start. The agent observes network connections over time, so a service that hasn't made any connections yet won't appear.
+
+**Verify the service is actually running** on a host with Sematext Agent installed. Services on hosts without agents won't be detected.
+
+```bash
+ps aux | grep <service-name>
+```
+
+**Check that the agent is on that host.** Each host needs its own agent instance. Use [Fleet](/docs/fleet/) to see which hosts have agents installed. If you've added new hosts to your infrastructure, ensure they have agents installed.
+
+**Look for network connectivity issues.** If the agent can't reach Sematext Cloud, data won't be transmitted. Check firewall rules and proxy settings.
+
+**Consider unrecognized services.** Network Map detects [over 100 service types](/docs/network-map/supported-services/), but custom or unusual services might appear with generic names rather than specific icons. They should still show up as processes or connections.
+
+## Missing Connections
+
+If services appear but connections between them don't:
+
+**Ensure there's active traffic.** Connections only appear when there's actual network communication. If a service hasn't sent or received data recently, its connections won't show.
+
+**Check if it's loopback traffic.** Connections to localhost (127.0.0.1) are filtered out by default since they're typically internal to a host.
+
+**Verify both endpoints have agents.** For a connection to appear, the agent needs to observe it. Connections to external services outside your monitored infrastructure show differently than internal connections.
+
+**Consider kernel limitations.** Some connection types may not be captured on older kernels. Kernel 5.8+ provides the best coverage.
+
+## Performance Issues
+
+If Network Map is slow or your browser struggles:
+
+**Zoom out.** At lower zoom levels, Network Map renders less detail per element, improving performance. Use the zoom controls to find a balance between detail and responsiveness.
+
+**Apply filters.** Instead of displaying your entire infrastructure, use [filters](/docs/network-map/filtering-search/) to focus on specific services, namespaces, or service types. Fewer elements means better performance.
+
+**Use Quick Filters.** If you're troubleshooting, Quick Filters like "High CPU" immediately narrow the view to relevant services.
+
+**Try a different browser.** Network Map uses modern browser features for rendering. Chrome and Firefox typically provide the best performance.
+
+## Incorrect Service Detection
+
+If services are detected with wrong names or types:
+
+Network Map identifies services using multiple signals: container image names, process names, environment variables, Kubernetes metadata, and port-based inference. Usually this works well, but sometimes:
+
+Custom services might not match any known patterns and appear as generic processes. Services with non-standard configurations might be misidentified. Heavily customized container images might confuse image-based detection.
+
+Currently, service detection is automatic and cannot be manually overridden. The detected service type affects the icon displayed and tier placement, but doesn't affect the underlying data collection.
+
+## Getting More Help
+
+If you're still experiencing issues:
+
+Check the [Sematext Agent troubleshooting guide](/docs/agents/sematext-agent/agent-troubleshooting/) for agent-specific issues.
+
+Check the [Sematext status page](https://status.sematext.com) for any ongoing platform issues.
+
+Review agent logs for specific error messages that might indicate the problem:
+
+```bash
+journalctl -u sematext-agent --since "1 hour ago" | grep -i error
+```
+
+Contact Sematext support with details about your environment, the issue you're experiencing, and any relevant log excerpts.
+
+## Next Steps
+
+- [Getting Started](/docs/network-map/getting-started/) to review prerequisites and setup
+- [Services View](/docs/network-map/services-view/) to understand how services are displayed
+- [Infrastructure View](/docs/network-map/infrastructure-view/) to navigate your infrastructure hierarchy
diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css
index ce91b4d11..4a199e145 100644
--- a/docs/stylesheets/extra.css
+++ b/docs/stylesheets/extra.css
@@ -639,19 +639,21 @@ pre {
 .node-icon { color: white; }
 .browser-icon { color: white; }
 .mobile-icon { color: white; }
+.network-map-icon { color: white; }
 
 /* Main categories - first grid */
 .grid.cards > ul > li:nth-child(1) { background-color: #1a237e; } /* Logs - Deep Indigo */
 .grid.cards > ul > li:nth-child(2) { background-color: #0277bd; } /* Monitoring - Ocean Blue */
-.grid.cards > ul > li:nth-child(3) { background-color: #00695c; } /* Experience - Deep Teal */
-.grid.cards > ul > li:nth-child(4) { background-color: #ef6c00; } /* Synthetics - Warm Orange */
-.grid.cards > ul > li:nth-child(5) { background-color: #d32f2f; } /* Alerts - Urgent Red */
-.grid.cards > ul > li:nth-child(6) { background-color: #2e7d32; } /* Events - Forest Green */
-.grid.cards > ul > li:nth-child(7) { background-color: #1565c0; } /* Dashboards - Royal Blue */
-.grid.cards > ul > li:nth-child(8) { background-color: #6a1b9a; } /* Tags - Deep Purple */
-.grid.cards > ul > li:nth-child(9) { background-color: #00838f; } /* Team - Cyan */
-.grid.cards > ul > li:nth-child(10) { background-color: #00695c; } /* Fleet - Teal */
-
+.grid.cards > ul > li:nth-child(3) { background-color: #00695c; } /* Tracing - Deep Teal */
+.grid.cards > ul > li:nth-child(4) { background-color: #7986cb; } /* Network Map - Light Indigo */
+.grid.cards > ul > li:nth-child(5) { background-color: #ef6c00; } /* Experience - Warm Orange */
+.grid.cards > ul > li:nth-child(6) { background-color: #d32f2f; } /* Synthetics - Urgent Red */
+.grid.cards > ul > li:nth-child(7) { background-color: #2e7d32; } /* Alerts - Forest Green */
+.grid.cards > ul > li:nth-child(8) { background-color: #1565c0; } /* Events - Royal Blue */
+.grid.cards > ul > li:nth-child(9) { background-color: #6a1b9a; } /* Dashboards - Deep Purple */
+.grid.cards > ul > li:nth-child(10) { background-color: #00838f; } /* Tags - Cyan */
+.grid.cards > ul > li:nth-child(11) { background-color: #00695c; } /* Team - Teal */
+.grid.cards > ul > li:nth-child(12) { background-color: #5e35b1; } /* Fleet - Purple */
 
 /* Improve contrast for card text and icons */
 .grid.cards > ul > li a,
diff --git a/mkdocs.yml b/mkdocs.yml
index 1da1d3a02..1f9130f8a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -104,6 +104,15 @@ nav:
       - Custom Metrics: monitoring/custom-metrics.md
       - Changelog: changelog.md
       - FAQ: monitoring/spm-faq.md
+    - Network Map:
+      - Overview: network-map/index.md
+      - Getting Started: network-map/getting-started.md
+      - Services View: network-map/services-view.md
+      - Infrastructure View: network-map/infrastructure-view.md
+      - Filtering & Search: network-map/filtering-search.md
+      - Thresholds: network-map/thresholds.md
+      - Supported Services: network-map/supported-services.md
+      - Troubleshooting: network-map/troubleshooting.md
     - Tracing:
       - Overview: tracing/index.md
       - Getting Started: tracing/getting-started.md