ADAM PULSE Knowledge Base
Network Operations · Troubleshooting · Process

Network troubleshooting checklist: a step-by-step guide to LAN, firewall, ISP and application faults

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published August 12, 2026·Last reviewed August 2026·ADAM Pulse Knowledge Base

When someone says:

"The network is down."

that statement tells IT almost nothing.

Is the problem:

Good network troubleshooting is not random.

It is a process of progressively narrowing the failure domain.

For ADAM Pulse and USA Telecom, a practical troubleshooting model is:

DEFINE → SCOPE → VERIFY → ISOLATE → TEST → ESCALATE → RESTORE → DOCUMENT

This checklist provides a repeatable process IT teams can use to investigate network incidents without immediately blaming the ISP, rebooting everything, or jumping randomly between tools.

What Is Network Troubleshooting?

Network troubleshooting is the systematic process of identifying, isolating and resolving connectivity or performance problems.

The goal is to move from:

"Something is broken."

to:

"The likely problem exists in this part of the network path."

That process should be evidence based.

What Is the First Step in Network Troubleshooting?

Start by defining the problem.

Ask:

What exactly is not working?

Avoid vague descriptions.

Instead of:

"The internet is slow."

determine:

Good troubleshooting begins with good intake.

Network Troubleshooting Checklist

Use this sequence:

  1. Define the symptom.
  2. Record the exact incident time.
  3. Determine scope.
  4. Check the endpoint.
  5. Check local connectivity.
  6. Check WiFi or LAN.
  7. Check DNS.
  8. Check the gateway.
  9. Check the firewall.
  10. Check the primary WAN.
  11. Check the backup WAN.
  12. Test multiple external destinations.
  13. Review latency.
  14. Review packet loss.
  15. Review jitter when relevant.
  16. Review routing or path.
  17. Check failover.
  18. Check the application.
  19. Review historical monitoring.
  20. Identify the probable failure domain.
  21. Escalate with evidence.
  22. Verify restoration.
  23. Document the incident.
  24. Look for recurrence.

Step 1: Define the Symptom

Determine what the user actually experiences.

Examples:

No internet

Website will not load

Zoom freezes

VoIP audio breaks up

VPN disconnects

Application is slow

These symptoms may have different causes.

Step 2: Record the Exact Time

The timestamp is critical.

Ask:

When did it start?

When did it stop?

Is it happening now?

Historical network data becomes much more useful when correlated to an exact time.

Step 3: Determine the Scope

Ask:

One user?

One department?

One location?

Multiple locations?

Everyone?

Scope immediately narrows the possibilities.

One User

Consider:

One Location

Consider:

Multiple Locations

Consider:

Step 4: Check the Endpoint

Before investigating the carrier, verify the user's device.

Check:

If one device is affected while everyone else works, begin locally.

Step 5: Check Physical Connectivity

For wired devices:

For network infrastructure:

Physical problems remain common.

Step 6: Check WiFi

If the user is wireless, evaluate:

Compare with a wired device when practical.

If wired works and WiFi does not, the ISP becomes less likely.

Step 7: Check IP Configuration

Validate:

An incorrect configuration can look like an internet outage.

Step 8: Test the Local Gateway

Can the endpoint reach its gateway?

If not, investigate:

Do not immediately escalate to the ISP.

Step 9: Test DNS Separately

Can the device reach an external IP address but not resolve a hostname?

If yes, investigate DNS.

This distinction is important:

Connectivity works

but:

Name resolution fails.

Users may still describe that as:

"The internet is down."

Step 10: Check the Firewall

Determine:

The firewall is a major troubleshooting boundary.

Step 11: Check the Primary WAN

Evaluate:

A circuit can be online but degraded.

Step 12: Check the Backup WAN

If the site has redundant internet, verify:

Do not assume WAN2 is healthy because WAN1 normally carries traffic.

Step 13: Test Multiple External Destinations

Avoid drawing conclusions from one target.

If:

Destination A fails

but:

B and C work,

the problem may be with A or its path.

If:

All external destinations fail simultaneously,

the issue may be closer to the site or carrier.

Step 14: Review Latency

Compare current latency against:

A major increase can indicate congestion, routing changes or carrier problems.

Step 15: Review Packet Loss

Determine:

Packet loss is particularly important for real time applications.

Step 16: Review Jitter

For:

review jitter where available.

A network can have acceptable average latency but inconsistent packet delivery.

Step 17: Review the Network Path

Use path testing to understand how traffic reaches the destination.

Look for:

Remember that individual network hops may treat diagnostic traffic differently, so interpret traceroute carefully and in context.

Step 18: Check for WAN Failover

Ask:

Did traffic move from primary to backup?

If yes:

Failover itself can explain short application interruptions.

Step 19: Check the Application

If infrastructure appears healthy, test the actual service.

Examples:

Infrastructure health does not guarantee application health.

Step 20: Review Vendor or Cloud Service Status

When appropriate, check whether the application provider reports a service issue.

Do not spend hours changing local infrastructure when the service itself is experiencing an incident.

Step 21: Review Historical Monitoring

If the problem is no longer occurring, history becomes critical.

Review the incident window for:

This is where continuous monitoring dramatically improves troubleshooting.

Step 22: Check What Changed

Ask:

What Changed Before the Problem?

Review:

A recent change is not automatically the cause, but it is an important clue.

Step 23: Identify the Failure Domain

Before escalating, classify the probable problem.

Endpoint

One device.

LAN or WiFi

Local connectivity.

Firewall

Network edge.

WAN or ISP

External connectivity.

DNS

Name resolution.

Application

Service or SaaS platform.

Cloud or Remote Network

External infrastructure.

The goal is not always to know the final root cause immediately.

The goal is to narrow the investigation.

Step 24: Escalate to the Correct Party

Once the failure domain is understood, involve:

Escalating too early to the wrong party wastes time.

What Information Should Be Included in an ISP Escalation?

Provide:

Avoid:

"Internet slow. Please investigate."

What Information Should Be Included in an Application Escalation?

Provide:

This helps distinguish application issues from network problems.

Step 25: Verify Restoration

Do not close an incident only because:

The ISP says it is fixed.

or:

The application vendor says resolved.

Independently validate:

Then confirm user experience where appropriate.

Step 26: Monitor Stability

A service that comes back for two minutes may not be truly restored.

Continue monitoring for recurrence.

Watch for:

Step 27: Document the Incident

Record:

Documentation turns individual troubleshooting into organizational knowledge.

Step 28: Look for Recurrence

One incident may be random.

Ten similar incidents are a pattern.

Historical monitoring should help answer:

Has this happened before?

Repeated incidents deserve deeper investigation.

What Is Root Cause Analysis?

Root cause analysis attempts to identify the underlying reason an incident occurred.

Examples:

Symptom:

Zoom froze.

Failure domain:

WAN quality.

Root cause:

Carrier packet loss caused by provider issue.

Do not confuse the symptom with the root cause.

What Is Fault Isolation?

Fault isolation narrows the problem to a specific network area.

For example:

User

→ LAN

→ Firewall

→ WAN

→ ISP

→ Internet

→ Application

Testing each boundary helps determine where normal behavior stops.

Why Is Fault Isolation Better Than Random Troubleshooting?

Random troubleshooting often looks like:

Reboot modem.

Change DNS.

Restart firewall.

Call ISP.

Reinstall application.

This may eventually work, but it can destroy evidence and consume time.

Fault isolation follows the network logically.

Should You Start with Ping?

Ping is useful, but it is only one tool.

It can help test:

But it does not fully evaluate:

Use it as part of a broader process.

When Should You Use Traceroute?

Traceroute can help understand network path and potential changes.

Use it when:

Interpret intermediate hop behavior cautiously because devices may deprioritize or block diagnostic traffic.

When Should You Use a Speed Test?

A speed test can help measure throughput.

It is useful when investigating:

But it should not be treated as the only network health test.

A high speed result does not eliminate:

When Should You Use Packet Capture?

Packet capture is a deeper troubleshooting tool useful when basic monitoring cannot explain the problem.

It can help investigate:

Packet capture generally requires more technical expertise and should be used purposefully.

What Network Troubleshooting Tools Should IT Teams Have?

A practical toolkit may include:

The best tool depends on the question.

What Is the ADAM Pulse Network Troubleshooting Model?

ADAM Pulse can organize troubleshooting around:

USER → LAN → GATEWAY → FIREWALL → WAN → CARRIER → INTERNET → APPLICATION

At every layer, ask:

Is it reachable?

Is performance normal?

What changed?

What does history show?

This creates a repeatable troubleshooting method.

The ADAM Pulse Troubleshooting Framework

DEFINE → SCOPE → VERIFY → ISOLATE → TEST → ESCALATE → RESTORE → DOCUMENT → LEARN

Define

Describe the actual symptom.

Scope

Determine who and what is affected.

Verify

Confirm the condition.

Isolate

Find the likely failure domain.

Test

Collect evidence.

Escalate

Engage the correct party.

Restore

Return service.

Document

Preserve the incident record.

Learn

Identify patterns and improvements.

A Network Troubleshooting Checklist Should Be Used Before the Outage

Do not invent the process while users are waiting.

Create:

before incidents occur.

ADAM Pulse Turns Troubleshooting into a Repeatable Process

The purpose of network monitoring is not simply to generate graphs.

It should help answer:

What failed?

Where did it fail?

When did it happen?

What remained healthy?

Has it happened before?

Who should act next?

ADAM Pulse provides managed network monitoring designed to help USA Telecom customers detect problems, preserve historical evidence, isolate network failure domains, and improve operational response.

Define the problem.

Follow the path.

Collect the evidence.

Escalate intelligently.

Verify restoration.

Learn from the incident.

Talk with USA Telecom about using ADAM Pulse to create a more systematic network monitoring and troubleshooting process.

Frequently asked questions

What are the basic steps of network troubleshooting?

Define the problem, determine scope, verify local connectivity, test the gateway, firewall and WAN, review DNS and application health, isolate the failure domain, escalate with evidence and verify restoration.

What should I check first when the internet is down?

First determine whether the problem affects one user or an entire location. Then check local connectivity and the gateway before assuming the ISP is responsible.

How do I tell whether a network problem is the firewall or ISP?

Monitor and test both boundaries independently. If the firewall remains reachable while external connectivity fails, the investigation may move toward the WAN or carrier path.

Is ping enough to troubleshoot a network?

No. Ping is useful for reachability, latency and loss testing, but complete troubleshooting may also require DNS testing, path analysis, firewall diagnostics, application testing and historical monitoring.

Why is historical monitoring important for troubleshooting?

Many intermittent problems disappear before technicians investigate. Historical monitoring preserves evidence from the actual incident period.

Sources

Editorial note

A single test from a single location at a single moment rarely proves where a fault sits. Correlate against history, test from more than one point, and preserve timestamped evidence before changing configuration or rebooting equipment.

Talk to us about your network security

USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.

Related articles

Ping vs traceroute vs MTR · Is it the ISP or the firewall? · What is network fault isolation? · How to troubleshoot packet loss · i · i

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us