Network Watcher is a collection of tools in Azure for monitoring, diagnosing, and understanding the networks you have built, so that you can find problems faster and see what your network is really doing.

Start with what a network does

A network moves messages between computers. When you run applications in Azure, many pieces must talk to each other: web servers, databases, load balancers, gateways, and offices far away. Each message passes through addresses, rules, routes, and devices. If any one of these is wrong, the message does not arrive, and the person using the application sees only a slow page or an error.

Why seeing is hard

In your own office, you could walk to the cable room and look. In the cloud, you cannot. The cables, switches, and routers belong to Microsoft, and you work only with software versions of them. You need tools that look inside the virtual network on your behalf and tell you what they find. Network Watcher is that set of tools.

What it gives you

• Diagnosis. Tools that answer questions like “Why can machine A not reach machine B?” and name the exact rule or route responsible.
• Visibility. A drawn picture of your network and records of the traffic that crossed it.
• Monitoring. Tests that run on a schedule and tell you when delay, loss, or reachability change.
• Evidence. Packet captures and logs that experts and auditors can examine later.
• Insight. Analysis of flow records to show who talks the most, what is blocked, and where traffic goes.

Cloud networks are built from software settings, and software settings are easy to get wrong. A tool that explains what the settings actually do is not a luxury.

The problem of many layers

A single message in Azure may pass through a security group on a subnet, another on a network interface, a route table, a firewall, a gateway, and a load balancer. Each of these may allow, block, or redirect the message. When something fails, the cause could be in any layer. Reading all the settings by hand takes a long time and people miss things.

The problem of invisible failures

Some failures never produce a clear error message. A rule blocks traffic silently. A route sends traffic into a dead end. A DNS name resolves to the wrong address. The application simply waits and times out. You need a tool that can say “this specific rule dropped this specific packet” instead of leaving you to work out the reason.

The problem of change over time

Networks that worked yesterday can fail today because someone changed a rule, a link became slow, or traffic patterns shifted. Without records, you cannot answer simple questions such as “When did this start?” or “What changed?” Logs and monitoring give you a memory.

What it solves in practice

Network Watcher uses ordinary networking words and a few of its own. Learn them once, and the documentation will read easily.

The five-tuple in plain words

Most diagnostic tools ask you for the same five facts. Where is the traffic coming from? On which port? Where is it going? On which port? And is it using TCP or UDP? Together these describe one conversation exactly. When you ask Network Watcher “would this be allowed?”, you hand it these five facts, and it replies with a clear yes or no and the rule behind the answer.

TCP and UDP

These are the two main ways of sending data. TCP is careful: it sets up a connection, numbers the packets, and resends any that go missing. Web pages and databases use it. UDP is quick and careless: it just sends, with no checking, which suits live voice, video, and some name lookups. Network Watcher tests need you to say which one you mean.

Network Watcher is not a single program. It is a family of tools that look at different parts of your network and send their results to different places.

flowchart TD
    subgraph NET["Your Azure Network"]
        VM1["Virtual Machine A"]
        VM2["Virtual Machine B"]
        NSG["Network Security Groups"]
        RT["Route Tables"]
        GW["VPN or ExpressRoute Gateway"]
    end
    subgraph NW["Network Watcher in the Region"]
        DIAG["Diagnostic tools: IP flow verify, next hop, connection troubleshoot, NSG diagnostics"]
        MON["Monitoring: Connection Monitor and topology"]
        CAP["Packet capture"]
        FL["Flow logs"]
    end
    NSG --> DIAG
    RT --> DIAG
    VM1 --> MON
    VM2 --> MON
    VM1 --> CAP
    NET --> FL
    FL --> ST["Storage account"]
    FL --> LA["Log Analytics workspace"]
    LA --> TA["Traffic Analytics charts"]
    MON --> LA
    CAP --> ST
    LA --> AL["Alerts and dashboards"]
    GW --> DIAG
    

Read the diagram from the top. Your network contains machines, security groups, route tables, and gateways. Network Watcher has four groups of tools. The diagnostic tools read the rules and routes to answer questions on demand. The monitoring tools run tests between machines on a schedule. Packet capture records data on a single machine. Flow logs record every conversation across the network. Results land in a storage account or a Log Analytics workspace, where charts, alerts, and dashboards can use them.

The on-demand tools

These answer one question when you ask it. You give the details, they check the configuration, and they reply within seconds. They do not need to stay running, and most do not need anything installed on your machines.

The continuous tools

Connection Monitor and flow logs work all the time. They produce a steady stream of results that build a picture of how the network behaves over days and weeks. They cost money while they run, because they produce data that must be stored and processed.

The capture tool

Packet capture works inside a virtual machine and requires an extension. It records actual packets, which is powerful and sensitive. It is used for hard problems, for short periods, and with care.

Where the data goes

Before you can use any tool, Network Watcher must exist in the region where your network lives. Understanding how this works avoids a common confusion for beginners.

One per region, per subscription

Network Watcher is a regional service. In each subscription, there can be one Network Watcher resource for each Azure region. If your virtual networks are in three regions, you need Network Watcher enabled in all three. A virtual network in East US is served by the Network Watcher in East US, not by one in another region.

Automatic enabling

When you create or update a virtual network in a subscription, Azure normally enables Network Watcher for that region automatically. The resource is placed in a resource group named NetworkWatcherRG, which Azure creates for you. Many people are surprised to find this group in their subscription. It is expected, and it is safe to leave alone. Deleting it removes the Network Watcher resources inside it.

Organizations can choose to turn off automatic enabling and create the resource in a resource group of their own choice, which fits better with naming and governance rules. Check current documentation for the exact steps and behaviors, since they have changed over time.

Permissions

Network Watcher uses Azure’s role-based access control. A person needs a role that allows them to read and run its tools. The built-in Network Contributor role is often used, and custom roles can grant only what is needed. Some tools need extra permissions on other resources too. For example, flow logs must be able to write to a storage account, and packet capture must be able to install an extension on a machine.

• Read-only staff can view topology and effective settings.
• Network engineers run the diagnostic tools and create monitors.
• Security staff read flow logs and analytics.
• Only a few trusted people should start packet captures, since they can record sensitive data.

What you need on the machines

Agent requirements and options have changed between versions of the service, so confirm them in the current documentation before you plan a rollout.

The first job of any troubleshooter is to understand what is actually there. Network Watcher offers views that draw the network and show the settings that really apply.

Topology

The topology view draws your virtual network as a diagram. You see subnets, network interfaces, security groups, route tables, load balancers, gateways, and how they connect. It is built from the live configuration, not from someone’s old drawing, so it always shows what exists now. It is a good way to take over a network you did not build, or to explain a design to others.

Effective security rules

A network interface may be covered by a security group on the subnet and another on the interface itself. Reading both and combining them in your head is error-prone. The effective security rules view does the combining for you. It lists every rule that applies to a network interface, in the order they are checked, from every group that touches it. This answers the question, “Given everything attached here, what is really allowed?”

Effective routes

The same idea applies to routing. Azure combines the built-in system routes, any routes you added in a route table, and routes learned from gateways. The effective routes view shows the final merged list for a network interface. It tells you, for any destination, which route wins and where the traffic will go next.

How to read the effective routes

Why these views matter

• They remove guesswork about which setting wins.
• They expose rules or routes that people forgot they created.
• They show the effect of gateways that add routes automatically.
• They give a clear screenshot or export to share in a support ticket.

These tools answer the most common question in networking: why does this specific connection not work? They check your settings in seconds and name the exact cause.

sequenceDiagram
    participant U as You
    participant NW as Network Watcher
    participant S as Security Rules
    participant R as Routes
    U->>NW: Is traffic from VM A to 10.0.2.4 port 1433 using TCP allowed?
    NW->>S: Read the rules that apply to VM A outbound
    S-->>NW: Outbound allowed by rule AllowVnetOutBound
    NW->>S: Read the rules that apply to the target inbound
    S-->>NW: Inbound denied by rule deny-sql-from-web
    NW-->>U: Denied. The blocking rule is deny-sql-from-web
    U->>NW: Where would traffic from VM A to 10.0.2.4 go next?
    NW->>R: Look up the most specific matching route
    R-->>NW: Next hop type is VnetLocal
    NW-->>U: The packet stays inside the virtual network
    

The diagram shows two typical questions. First you ask whether a particular kind of traffic is allowed. Network Watcher reads the rules in both directions and tells you the verdict and the name of the rule responsible. Then you ask where the traffic would go next, and it reads the routes and reports the next hop. Together, the two answers cover the two biggest causes of connection trouble: filters and paths.

IP flow verify

IP flow verify checks one specific flow against the security rules of a virtual machine’s network interface. You supply the direction, protocol, local and remote addresses, and ports. It replies “Access allowed” or “Access denied”, and it names the rule that decided. It looks at the real, combined rules, including those from security groups on both the subnet and the interface.

• It checks only security rules, not routes, firewalls outside the group, or the machine’s own firewall.
• A result of “allowed” does not prove the connection works; it only proves Azure’s rules are not the cause.
• It is best for quick yes-or-no questions about a single flow.

NSG diagnostics

NSG diagnostics goes a step further. Instead of one machine’s interface, it examines a flow across all the security groups that apply, and shows how each group treats it. It can even evaluate flows described through service tags or address ranges, which is useful for checking a rule change before you make it, or for finding out which groups are responsible. Its availability and features have been changing, so check current documentation.

Next hop

Next hop tells you where a packet leaving a machine will be sent first on its way to a destination. The answer includes the type of hop and, when relevant, the address of the device. The common types are:

Next hop also reports which route table entry made the decision. This is how you catch a user-defined route that sends traffic somewhere unexpected, or a missing route that leaves it stuck with the default.

The tools in the last chapter read settings. Connection troubleshoot goes further: it actually tries to connect, and tells you what happened along the way.

What it does

Connection troubleshoot sends real test traffic from a virtual machine in Azure to a destination, such as another machine, a name on the internet, or an address on a given port. While doing so, it measures how long the trip takes, records each hop on the path, and checks whether the connection succeeded. It also looks for configuration problems on the way and reports them, such as a blocking security rule or a route that sends traffic nowhere.

What you provide

• Source: a virtual machine in Azure that has the Network Watcher extension installed.
• Destination: an address, a name, or another Azure resource.
• Port and protocol: for example TCP on port 443.

What you get back

Typical uses

• Testing that a web server can reach its database before the application goes live.
• Confirming that a machine can reach a service on the internet through a NAT gateway or firewall.
• Finding where traffic stops on the way to an on-premises server through a gateway.
• Checking delay between two machines in different regions.

Limits and changes to know about

Because it sends real traffic, it needs the extension on the source machine and permission to run. It is a point-in-time test, so a problem that happens only sometimes may be missed. For continuous testing, the better tool is Connection Monitor, explained in the next part of this guide. Microsoft has been moving the features of connection troubleshoot toward Connection Monitor, so check current documentation to see whether you should start with one or the other.

A single test tells you what is true right now. Connection Monitor repeats tests all day and every day, so you can see trends and catch problems that come and go.

What it is

Connection Monitor is the continuous testing tool of Network Watcher. You define a set of sources, a set of destinations, and the tests to run between them. It then sends probes on a schedule, measures the results, and stores them. You can view the history as graphs, see which paths are healthy, and set alerts when something crosses a limit.

The building blocks

What it measures

• Reachability: whether the destination answers at all.
• Round-trip time: how long a probe takes to go and return.
• Check failures: the percentage of probes that did not succeed.
• Path topology: a hop-by-hop view that can show where on the path the delay or loss begins.

Why it beats one-off tests

The older tool it replaced

Earlier, Azure had separate tools called Network Performance Monitor and the older classic connection monitor. Microsoft has retired them and pointed users to the current Connection Monitor. If you read older articles that describe those tools, treat them as history and check the current documentation for migration notes.

Choosing what to test

Do not test everything. Pick the paths that matter most to the business: the web tier to the database, the office to the application over the VPN or ExpressRoute, the application to its key outside partner. A small number of well-chosen tests with sensible alerts is more useful than hundreds of tests that nobody reads.

When the higher-level tools cannot explain a problem, packet capture lets you look at the actual data passing through a machine’s network card, packet by packet.

What it does

Packet capture records the packets that enter and leave a virtual machine’s network interface. It works through the Network Watcher extension on the machine. You choose how long to record and how much to keep. The recorded data is saved in a file in a storage account or on the machine itself. You then open the file with a tool that reads capture files and examine each packet, its addresses, its flags, and its timing.

When to use it

• A connection starts but stalls partway, and you need to see who stopped answering.
• You suspect a device is resetting connections or changing packets.
• An application complains about corrupted or missing data.
• You need evidence for a vendor or a security investigation.
• You want to confirm exactly which addresses and ports an application really uses.

Filters keep it manageable

A busy machine produces enormous numbers of packets. Without filters, the capture grows quickly and becomes hard to read. You can restrict the capture to chosen protocols, source and destination addresses, and ports. You can also limit the number of bytes kept from each packet, and set a maximum file size and time limit. Narrow captures are faster to analyze and safer to store.

Steps for a good capture

Limits to remember

• It captures on one machine at a time, so a full picture may need two captures at both ends.
• Encrypted traffic shows addresses and timing, but not readable content.
• There is a maximum duration for a single session, which you should check in current documentation.
• It needs the extension installed, and the machine must be running.

Connections between Azure and your offices rely on gateways. When a tunnel drops or never comes up, Network Watcher can look inside the gateway for you.

VPN troubleshoot

The VPN troubleshoot tool checks the health of a VPN gateway and its connections. You select the gateway or a single connection and give it a storage account. The tool runs a series of checks and writes a detailed report and log files. It looks for problems such as mismatched settings, failed negotiation, expired keys, or a stopped gateway. The report names likely causes and suggests where to look next.

• It works for both gateways and individual site-to-site connections.
• It gives a health status, such as healthy or unhealthy, and a summary of what was found.
• Log files can be downloaded to share with a network team or with support.

What commonly goes wrong with tunnels

ExpressRoute and other gateways

For ExpressRoute, the main checks live in the circuit, peering, and gateway pages, plus the monitoring tools. Network Watcher helps by showing the effective routes learned from the gateway, running next hop to see if traffic uses the gateway, and running Connection Monitor tests between Azure and on-premises machines. Together, these show whether routes were learned, whether traffic takes the gateway path, and how the delay behaves.

A sensible order for gateway problems

1. Check the gateway and connection status in the portal.
2. Run VPN troubleshoot, and read the summary.
3. Check the effective routes on a machine behind the gateway.
4. Run next hop for an on-premises address, and confirm it points at the gateway.
5. Run a Connection Monitor or connection troubleshoot test to a machine on the other side.
6. Compare the settings on the on-premises device with those in Azure.

Diagnostic tools answer a question now. Flow logs keep a record of every conversation, so that you can answer questions about the past as well.

flowchart LR
    A["Packet crosses the network"] --> B["Platform notes the flow details"]
    B --> C["Flow records collected every minute"]
    C --> D["Written to a storage account as JSON files"]
    D --> E["Optional: processed by Traffic Analytics"]
    E --> F["Stored in a Log Analytics workspace"]
    F --> G["Queried, charted, and alerted on"]
    D --> H["Kept or deleted by retention policy"]
    G --> I["Insights lead to rule changes"]
    I --> A
    

The diagram traces one flow record through its life. A packet crosses the network, and the platform notes the conversation details. Records are gathered each minute and written to a storage account. If Traffic Analytics is switched on, they are also processed and stored in a Log Analytics workspace, where you can query, chart, and alert on them. What you learn leads to changes in rules, which changes the traffic, and the loop continues. Meanwhile, a retention policy decides how long the raw files are kept.

What a flow log contains

Each record describes a conversation using the five-tuple: source address and port, destination address and port, and protocol. It also says which direction the traffic went, which rule handled it, and whether it was allowed or denied. Newer versions of the log add information about how many packets and bytes were exchanged, and the state of the connection. The records are summaries, not copies of the data itself. They show who talked to whom, but not what they said.

What you can learn from flow logs

• Who is connecting to a sensitive machine, and from where.
• What is being blocked, which may show attacks or applications trying to reach things they should not.
• Which rules are never used, so they can be removed.
• Which ports and protocols are really used, so rules can be tightened to match.
• How much traffic flows between parts of the network, to guide planning and cost.
• Evidence for investigations after an incident.

Where flow logs are stored

Retention

Set a retention period for flow logs in storage, based on rules and need. Keeping logs forever costs money. Keeping them too briefly may leave you without evidence when you need it. Some regulations set minimum periods. Agree the number with your security and compliance teams.

Flow logs exist in two generations. Knowing the difference matters, because Microsoft has announced a move from the older kind to the newer.

The older kind: NSG flow logs

NSG flow logs record traffic at the level of a network security group. You switch them on for each group, and they record flows that were allowed or denied by that group’s rules. They have been the standard for years and appear in many guides and tools. However, they only see traffic that passes through a group, and they require turning on logging group by group.

The newer kind: virtual network flow logs

Virtual network flow logs record traffic at the level of a virtual network, a subnet, or a network interface, instead of at the group. They aim to be simpler to manage and to cover more cases, including traffic that is not subject to a security group. They record information about whether a flow was allowed or denied under the rules, and about the state of the connection and the volume of data. They can be enabled for a whole network at once, which makes coverage much easier to achieve and prove.

What this means for you

Microsoft has announced that creating new NSG flow logs would stop at a set date and that the older logs would be retired later, with a recommendation to migrate to virtual network flow logs. The exact dates, migration steps, and behavior have been published in Microsoft’s documentation and may be updated. Check them before you plan, and treat any date quoted in an article as a hint rather than a fact.

A migration plan

Watch out for differences in data

The records may use different field names, different structure, and different counts of flows. Queries written for one format may not work on the other. Test your dashboards and alerts with the new data before relying on them.

Raw flow logs are files full of lines. Traffic Analytics turns them into maps, charts, and tables that a person can read and act upon.

What it does

Traffic Analytics reads your flow logs, adds extra information such as geography, known malicious addresses, and Azure resource names, and stores the result in a Log Analytics workspace. You then browse dashboards that show how traffic moves through your network, or run queries for your own questions.

What you can see

Processing interval

Traffic Analytics processes logs at a chosen interval. A shorter interval gives fresher charts and costs more, and a longer interval is cheaper but slower to show change. The options and defaults can change, so check the current documentation and pick the interval that matches how fast you need to react.

How to use it well

• Review denied traffic weekly. Look for patterns, not single events.
• Check open ports. Rules that allow ports nobody uses are candidates for removal.
• Watch for unexpected destinations. A database server talking to a country you do not do business with deserves a question.
• Use it for planning. Traffic between regions and out to the internet guides cost decisions.
• Create saved queries for the questions you ask again and again.

Cost awareness

Traffic Analytics charges for the volume of flow data it processes, plus the storage of results in the workspace. In a large estate, this can become one of the larger monitoring costs. Limit it to the networks where the insight is worth the price, and shorten workspace retention where long history is not needed.

Data that nobody looks at does not help. This chapter shows how Network Watcher results reach people, at the right time and in the right shape.

Alerts

Azure Monitor can raise an alert when a measure crosses a limit. Connection Monitor produces metrics such as failed checks and round-trip time, which are natural alert sources. Log Analytics queries over flow data can also trigger alerts, for example when denied connections to a database jump suddenly. Alerts can email people, send messages to chat, create tickets, or start automated responses.

Dashboards and workbooks

Azure dashboards and workbooks let you gather charts from many sources onto one page. A good network dashboard shows the status of key tests, traffic volumes, denied flows, and gateway health. Show it on a screen in the team room, and review it in your regular meetings.

Integration with other tools

• Microsoft Sentinel and other security tools can read flow data to detect threats.
• Event hubs can stream logs to outside systems.
• Automation can run scripts or workflows when an alert fires, for example to collect a packet capture when a test fails.
• Ticketing systems can receive alerts and attach diagnostic results.

Avoiding alert fatigue

Too many alerts teach people to ignore all of them. Start with a few meaningful alerts. For each one, write down who responds and what they do. If an alert fires often and nobody acts, change its threshold or remove it. Alerts should point to real problems, not to normal variation.

The tools that see everything in your network are themselves worth protecting. Used well, Network Watcher improves security. Used carelessly, it can create new risks.

Who may do what

Give each person only the permissions they need. Reading topology or effective rules is low risk. Running diagnostic tests is moderate. Starting packet captures, reading flow logs, and changing monitors are higher risk, because they can reveal sensitive information about how systems talk to each other. Use custom roles to separate these duties.

Protect the stored data

Use the tools to improve security

• Check rules before and after changes using IP flow verify and NSG diagnostics.
• Use flow logs to find overly broad rules and replace them with specific ones.
• Look for traffic between tiers that should not talk, and block it.
• Check that management ports are not reachable from the internet.
• Feed flow data to security tools for threat detection.

Privacy and compliance

Flow logs record addresses, which can count as personal data in some places. Packet captures may contain even more. Check the rules that apply to your organization and region about collecting, keeping, and sharing this information. Document why you collect it, who can see it, and when it is deleted. Involve your legal and privacy teams early.

Resource locks and governance

Use Azure Policy to require flow logs on new networks, and to stop people from turning them off. Use resource locks on the resource group that holds Network Watcher, so that accidental deletion does not remove your tools. Track changes to monitors and logging settings through the activity log.

Many of Network Watcher’s tools are free to use, but the tools that keep running and store data carry charges. Knowing where the money goes keeps the bill predictable.

What is usually free

• Network Watcher itself, as a resource that exists in a region.
• Topology views, effective security rules, and effective routes.
• On-demand diagnostic checks such as IP flow verify and next hop, within current service terms.

What usually costs money

Cost levers in order of impact

Cost of not monitoring

It is easy to focus on the bill for monitoring and forget the cost of blindness. An hour of downtime for a busy application, or a security incident that cannot be investigated because the logs were never on, can cost far more than a year of monitoring. The goal is balance, not zero spending.

Real networks span regions, offices, and the internet. Network Watcher offers a few more views for these wider questions, and a few habits for using the tools across many networks.

Looking across regions

Because Network Watcher is regional, a company with networks in several regions has several instances to manage. Connection Monitor can test across regions, which shows whether delay between two regions is normal. Keep a naming standard so that tests and logs from different regions are easy to match up, and use one shared workspace or a clear workspace plan so results are not scattered.

Hybrid monitoring

For networks linked to offices through a VPN or ExpressRoute, the interesting question is often, “How is the path between the office and Azure behaving?” Connection Monitor can use on-premises machines as sources or destinations, if they have the monitoring agent. The result is a view of delay and loss across the hybrid link, which helps tell the difference between a problem in Azure, a problem in the link, and a problem in the office.

Internet-facing views

Habits for many networks

• Standardize names for monitors, workspaces, storage accounts, and resource groups.
• Use code to deploy monitors and flow logs, so every new network gets them automatically.
• Use policy to require logging on networks, and to report networks that lack it.
• Choose workspaces by ownership and compliance needs, not by whim.
• Share runbooks across teams, so everyone uses the same first steps.

Working with other Azure tools

Network Watcher is one part of a bigger picture. Azure Monitor collects metrics and logs from many services. Azure Firewall and Application Gateway keep their own logs. Log Analytics brings them together. Service Health tells you about platform problems that are not your fault. When you troubleshoot, use Network Watcher for the network path, and the others for the devices and services along it.

Experienced architects write down major choices as short decision notes. Here are common decisions for network monitoring, written in that style so you can see how the reasoning goes.

Patterns that work

Anti-patterns to avoid

This chapter gathers lessons that many teams learn the hard way. You can learn them the easy way, by reading them first.

Best practices

• Check the region first. Make sure Network Watcher exists in the region of the resource you are diagnosing.
• Start with the simple tools. Effective rules, effective routes, IP flow verify, and next hop answer most questions in minutes.
• Test with the full five-tuple. Give accurate source, destination, port, and protocol, or the answer will mislead.
• Remember the other layers. The machine’s own firewall, the application, and DNS are outside what security rule checks can see.
• Enable flow logs early, with a retention period agreed with security and compliance teams.
• Prefer virtual network flow logs for new work, and plan migration from the older logs.
• Use Connection Monitor on the paths the business depends on, with sensible thresholds.
• Protect the data. Secure storage, limit who can read logs, and control packet capture.
• Deploy by code and enforce by policy, so coverage is consistent.
• Create a baseline of normal behavior soon after launch.
• Link alerts to runbooks and review them regularly.
• Review cost every quarter.

Common mistakes

Here are typical ways organizations use Network Watcher. These are common patterns described in general terms, not accounts of any named company.

A typical online retailer on a sale day

A retail company sees checkout slowing down during a big sale. The team opens Connection Monitor and sees that round-trip time between the application tier and the payment partner has doubled since noon. The hop view shows the delay begins at the outbound firewall. Flow logs show a large number of connections from one batch job that started at the same time. The team moves the batch job to the night and the checkout recovers. Because the tests and logs already existed, the diagnosis took twenty minutes instead of a day.

A typical bank auditing its rules

A financial company must prove that databases are reachable only from the application tier. The security team enables virtual network flow logs on production networks and sends them to Traffic Analytics. A monthly review lists every source that connected to the database subnet. Two unexpected sources appear: an old reporting tool and a test machine. Both are removed, and the rules are tightened. The saved logs become part of the audit evidence.

A typical software company debugging a new deployment

A development team deploys a new service, and it cannot reach its database. The engineer runs IP flow verify, which reports that the database subnet’s security group denies the port. A rule was written for the wrong application security group. After correcting it, the engineer runs the check again to confirm. The whole fix, from complaint to confirmation, takes ten minutes.

A typical company with a flaky VPN

A manufacturer with a site-to-site VPN to a factory sees the connection drop every few hours. VPN troubleshoot reports repeated renegotiation failures. A side-by-side comparison of settings shows that the key lifetime on the factory device differs from the one in Azure. After the match is made, the tunnel stays stable, and a Connection Monitor test is added to alert the team if it ever drops again.

A typical health organization investigating a stall

An application that sends large images to an archive stalls partway through some transfers. Rules and routes look right. A short, filtered packet capture shows that large packets are not getting through while small ones do, a sign of a size mismatch somewhere on the path. The network team adjusts the packet size settings on the device and the problem disappears. Packet capture found what higher-level tools could not.

Who uses which tool

When a connection fails, an ordered approach finds the cause quickly. This playbook uses Network Watcher’s tools in the order that usually works best.

The method

Common symptoms and likely causes

Quick answers to questions beginners ask most often.

Network Watcher turns your Azure network from a black box into something you can see, test, and record. It rewards habits of diagnosing before changing and logging before incidents.

In this guide you met Network Watcher as the control room of your Azure networks. You learned how it is enabled per region, how topology and effective settings show what really applies, and how IP flow verify, NSG diagnostics, next hop, and connection troubleshoot answer questions about a single connection. You saw how Connection Monitor tests over time, how packet capture reveals the details, how VPN troubleshoot examines gateways, and how flow logs and Traffic Analytics record and summarize conversations. You also covered alerts, security, cost, patterns, common mistakes, and a playbook for troubleshooting.