What is External Monitoring and How does it Differ From Internal Monitoring?

You likely do not own your server, but you do have an interest in making sure the applications you run on your server remain responsive. You need to know the full story, and a combination of external and internal monitoring is how you get there.

Marketers understand the word “responsive” to mean “capable of rendering on any screen”, but we can think about responsive in more fundamental terms. Your site can be said to be responsive when it serves content to the end user in a timely fashion. Everyone has a different baseline, but under 4 seconds is a good mark to shoot for.

So how can internal or external monitoring help?

Let’s say you’re an independent contractor and you manage an art gallery’s website with art that has gone viral. Your client starts complaining their users can’t access the site. Internal monitoring might clue you into a sudden increase in bandwidth caused by a surge in end users trying to view these most precious of artistic works.

An Enterprise company has the same problem at a much larger scale. Yes, support staff and DevOps help, but there is a correlation between the size of a service and the difficulty in detecting its responsiveness. Enterprise users manage hundreds or sometimes thousands of services that all experience varying degrees of severity during an outage.

Monitoring and observability tell you more about these systems, and rely on knowledge of the internal and external workings of your system.

Internal Monitoring

Internal monitoring runs inside your server, and it focuses primarily on system resources. It reports the status of resources in real-time in most cases, and often users can track a wide range of hardware metrics. These usually include:

  • CPU load
  • Memory usage
  • Processes
  • Disk space
  • Traffic or bandwidth consumption

Internal monitoring is like giving your server a physical. It tells you what’s working, how well it’s working, and allows you some insights into the inner workings of your application.

It’s common to check for disk space, bandwidth, CPU usage, and general network traffic with internal monitoring

Private location monitoring is one example of internal monitoring that looks at resources behind your firewall. An installable agent that monitors resources is another example.

Internal problems can be one of the first warning signs that an outage is coming, so internal monitoring alerts users at the first signs of trouble. If you see a sudden spike in bandwidth consumption, or CPU or disk space is low, internal monitoring can alert you.

External Monitoring

External monitoring is the opposite, where you are pinging a service port for connectivity. You want to know if it’s actually up or down, and ideally what the user can see when the content is served. External monitoring is a bit more focused on the customer or end user perspective, often asking the additional question “can it run better?”

External monitoring usually measures response of something: detection of a string of text, an asset loading, an API response, or just a server code 200 to name a few examples. 

The key to external monitoring is that it must reside outside your infrastructure, and it’s typically also automated. This can make true external monitoring a challenge to manage in house, as it requires several locations observing your site continuously.

Combining Internal and External Monitoring

Data is king when you are optimizing, improving, or even just developing your application. You want to know what users want to see, how well the application performs, and what you can improve.

Internal and external monitoring help fill in some of these missing pieces. For example, internal monitoring can signal which parts of your application are the most resource intensive.

Real user monitoring can help you understand more about the application performs for real users, browser by browser or even broken down by mobile device.

Basic HTTP(S) monitoring tells you whether the site is accessible.

Errors seem less elusive when you can correlate the downtime to spikes in bandwidth consumption, or some other internal factor. Combining these monitoring types also tells the story of an outage.

The ideal setup is a combination of these important check types. Remember, monitoring often relies on other monitoring. If your server goes down, your internal monitoring usually follows. External monitoring may be your only insight into the problem during these outages.

Monitoring from both external and internal perspectives is an important safeguard in defending the Uptime and SLA obligations of your application. Building a more observable system also leads to better time to resolution, as you can respond to an outage with more technical data. Start monitoring now so you can build this data as you grow.

Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.

Get Started

Don't forget to share this post!

Richard Bashara is Uptime.com's lead content marketer, working on technical documentation, blog management, content editing and writing. His focus is on building engagement and community among Uptime.com users. Richard brings almost a decade of experience in technology, blogging, and project management to help Uptime.com remain the industry leading monitoring solution for both SMBs and enterprise brands. He resides in California, enjoys collecting and restoring arcade machines, and photography.

Catch up on the rest of your uptime monitoring news