Blog post
“Traceroute? You mean the thing I can type at the command line? Why would I even want to set up a test for that?”
This is, believe it or not, a comment we hear a lot at Catchpoint. At least from folks who are either new to tech, new to monitoring, or new to Catchpoint (or all three). It’s a common misconception.
It’s also something I’m not going to spend a ton of time addressing here. This blog is not meant to convince you why traceroute is super useful (even though it is). If you want more along those lines, I would like to suggest “How to Read a Traceroute”, which digs into both the history of the technology and the modern real-world use cases traceroute solves.
Instead, this guide is about one thing: giving you a jump-start to building your first (or even your next) traceroute test. It’s going to focus on the bare-minimum steps you need to get the job done, but I’ll also take some time to explore the other optional (but no less interesting) elements of a test.
Let’s get started.
How do I set up a traceroute test in Catchpoint?
Before you begin, make sure you have two things ready:
- A target for the traceroute (an IP address or public-facing URL)
- A Product or Folder where the test will live in Catchpoint
Friendly PSA: Your office printer is not a valid target. Unless you have that connected to the public Internet and OH FOR THE LOVE OF PANTS DON’T DO THAT. WHY WOULD YOU WANT TO DO THAT?!?
Ahem.
For more about Product and Folder locations, see here
Go into the Catchpoint portal and click "Control Center" from the left-hand navigation.
Select the Product or Folder (if you want. But if you don't pick now, you will be asked to select one after the next step)
Scroll down and you will see 5 options below "Traceroute".
These are:
If you're not sure which one you need, click each of the links above to see the differences.
Since you asked: Traceroute InSession is Catchpoint’s unique solution to several problems with “regular” traceroute. It’s a patented approach unique to Catchpoint. For more information about it, check out this article.
NOTE: DO NOT PANIC. You can change the test type later in this process, so don’t stress about locking it in just yet.
If you didn't select a Product or Folder before, you'll have to make a selection now.
That will open up your traceroute test properties screen.
What are the required fields for a traceroute test?
The required elements for your test are:
- Test name - This is the name of the test. Not much more to say here.
- Monitor – This is the type of Traceroute test to do. You picked it before, but this is your chance to change it if you want.
- Test Location – Possibly the part of the test you are most interested in – it’s the thing you are setting up a traceroute TO. This can be an IP address (1.2.3.4 – no, don’t use that IP as a test. What are you, a reprobate?) or domain name (like catchpoint.com and if you REALLY want to test to our website, that’s fine. Why should google get all the attention?)
- Run From – You set the start and end date and time of the test. Yes, you HAVE to specify an end date. You also need to eat all your vegetables. Look, I don’t make the rules, that’s just how things are.
- Nodes (Agents) – this is the location the test will be run from. You can select from any one of our 3,000 (at the time of this writing) agents, located across the globe.
NOTE: This might be automatically applied based on the Property or Group settings.
Believe it or not, those are the only requirements for this test. There are, however, a bunch of other items you ought to fill in. Before I do, I’d like to direct your attention to the left-hand area of the screen:
How does Catchpoint calculate the cost of a traceroute test?
Now, I know you’re probably not the person who deals with paying the bills at your company. But someone over there cares about how much things cost. That’s not to say Catchpoint requires a Brinks truck full of cash to operate. Quite the opposite. But folks in purchasing don’t like surprises, even if the “surprise” is that the cost doubled from $50 to $100. This is your chance to avoid getting an email from them asking questions.
Without getting too sidetracked, Catchpoint uses a point-based pricing model. Each test consumes a certain number of points depending on factors like:
- Test type
- Number of agents
- Test frequency
- Complexity and resource usage
For example:
- A basic traceroute test from a single agent might cost 121 points.
- Add a second agent? That jumps to 152 points.
- Change the test frequency from every 6 hours to every hour? You’re now at 730 points.
Tip: There are dashboards that show the current consumption of points across your Catchpoint account, but it still pays (literally) to be aware of the relative cost of what you’re creating.
What do “Inherit / Inherit & Add / Override” mean in test settings?
Some sections will be hidden unless you change this block from “Inherit” to something else. This is because – as the text implies – you’re inheriting those settings from the defaults (usually set at the “Property” level).
Here’s what each option does:
- Inherit – as already mentioned, this means the settings created elsewhere will be applied here.
- Override – This will ignore the previously-established settings, and let you set different options for this test.
- Inherit & Add – First, this option isn’t always available, so if you’re not seeing it, don’t immediately change your glasses prescription. Second, this option, when visible, lets you override some of the settings, but not all of them.
Additional optional fields you might encounter
Easy-peasy, right? OK, let’s get back on track! There are a few elements that are required (marked with an asterisk) but you usually won’t need to deal with them.
They are:
- Description – Don’t overthink this one. It’s just for your own awareness.
- Status – This allows you to toggle the test as active or not.
- Index – This lets you group several tests together so you can display an individual test in relation to the average of the test group (i.e. the index).
- Labels – These are freeform “labels” that you can use in other areas of Catchpoint including dashboards, reports, and alerts. They would allow you to set if/then triggers, or group elements on a screen, or any number of other cool things.
- Test Data Webhook – This is the webhook you would use to connect to the test results via API and export the data into other tools, graphing systems, etc.
- Thresholds – When this test is considered to be in a “warning” state. You have the option to set these thresholds in terms of millisecond (ms) response time, % availability, or both.
How do I configure performance thresholds?
Thresholds define when your test is considered to be in a Warning or Critical state. Here’s what to keep in mind:
- You must set a threshold for response time (ms)—it’s required.
- The Critical threshold must always be worse than the Warning threshold.
- For the response time (ms) setting, Critical needs to be higher.
- For % Availability, Critical needs to be lower.
These thresholds trigger visual indicators in dashboards and can be used to power alerts.
How do I control when and where my test runs?
If you’re testing from multiple locations, Catchpoint gives you flexibility in how the test executes:
- Run On – Presuming you’ve set up more than one agent, you can specify whether the test runs on every agent every time, or if it should run on a (random) sub-set of agents. This is a way of keeping point cost down while ensuring you have visibility across the entire range of agents.
- Agent Distribution – tying into the “Run On” option, this determines whether the test runs at the same time on every node, or at random intervals across nodes.
- Run Schedule – Set how often the test runs.
- Maintenance Schedule – Define periods when tests should be paused or ignored.
How do alerts work in a basic test setup?
Alerts notify you when thresholds are crossed. In a basic setup, you can define:
- Alert Recipients – A comma-separated list of email addresses for people who should receive alerts when a threshold is crossed
- Alert Subject – The subject of the email that recipients will receive. Note that there is a healthy list of variables (called “macros”) you can use within the subject field. For a complete list of those macros, see the documentation here.
NOTE: This is just the default setting for a basic alert. Catchpoint supports far more alert nuances than this but delving into it goes beyond the scope of this blog. We’ll dive deep into alerts in a future post.
What happens after you create a traceroute test?
If you’ve followed along until this point, you’ll have a functional traceroute test set up. Now you can click “Save” and bask in the warm glow of a job well done.
Now you can… uh… actually, what CAN you do now?
Obviously, the test is collecting data. But where is it? How can you see it? And – besides looking at it lovingly – what can you do with it?
How do I view and analyze traceroute test results in Smartboards?
One of the first ways to view the data from any test is using Smartboards
From within the test itself, you’ll see the Smartboard option at the top left corner.
But that’s not all. If you click the little down-y-arrow-thingy (Don’t laugh, this is a very technical term.) you’ll see some other options:
Performance
This is the default Smartboard view and includes:
- % Downtime: How often the target destination was unavailable.
- Network Metrics (ms): Round-trip time (basically ping) and the amount of jitter, both expressed in milliseconds.
- Network Metrics (%): Packet loss as a percentage of total packets transferred.
- Experience Score: A composite metric which grades the overall digital experience of individual tests or groups of tests on a scale of 0-100.
- Event summary: Key events (errors, alerts triggered, and more.
Scatterplot
Think of this as the “Performance” option but without the connecting line. While traceroute might not generate the most thrilling graph you’ve ever seen, for other types of data it can be very informative.
You’ll see:
- Average test time (ms)
- % Availability
It's important to note that at the bottom of the graph area, somewhat hidden if you don’t know to look for it, is another section that’s worth your time. This area appears in other graphs, but I’m taking a moment to talk about it here.
You can expand this area by dragging up on the double-lines in the center. Depending on the type of graph you are showing, you’ll see tabs for a summary table, Errors, and Purge.
What is the summary table and why is it useful?
Summary Table provides a columns-and-rows view that shows:
- The number of tests (runs) shown on the graphs above
- Overall averages for other data shown in the graphs above (Test time, availability, etc.
Errors: As the name implies, this has details on the errors that have occurred with regard to this test.
Purge Summary: A list of any data that has been selected to be purged (a function covered elsewhere).
The Summary Table view gives you a compact, actionable snapshot of test behavior, errors, and cleanup history—making it easier to validate data or debug quickly.
What do the Statistical and Records views in Smartboard reveal?
Statistical view: The statistical smartboard provides you with 3 charts instead of one:
- 95th percentile test time (ms)
- Median test time (ms)
- Geometric mean (GM) test time (ms)
It’s worth noting that, like the Scatterplot graph, this Smartboard has a Summary Table area at the bottom.
Records view: This option doesn’t open a new chart area but instead opens up a sub-panel showing the last few tests and their results (failure or success, and if successful, the test time). This is meant to be used for troubleshooting the test itself, either when you first create it or if it starts to have problems later on.
Together, the Statistical and Records views help you validate test stability and performance patterns over time. Use them to pinpoint trends, troubleshoot problems, and ensure your tests are running as expected.
While there’s a lot more to know about building dashboards in general, that topic is outside the scope of this blog. Trust that we will get to it in a future installment.
Can I add my traceroute test to dashboards or alerts?
Not to sound like a broken reco… geeze that’s an old reference. Hmmm… Not to sound like the lowest Spotify plan? Nah. You know what? Go ahead and shoot me your best replacement for the “broken record” cliché in the comments.
But I digress. My point is that the process of building dashboards and alerts really is outside the scope of this blog. So, I will simply say that your new traceroute test would look great in a flashy new dashboard (or a hardworking old one). But getting it in there isn’t something we’ll be covering here.
Nor are we going to dive into all the amazing nuances of crafting a useful, informative, actionable alert. Not because you don’t need them, but because this blog is long enough as it is.
Why does test location diversity matter for traceroute
One of the immediate and obvious drawbacks to the “do it yourself” approach with traceroute is that you can only test from the point of view you have (meaning the system you’re currently on). This doesn’t come anywhere close to what anyone would consider comprehensive visibility.
In order for traceroute (or any monitoring test, really) to be effective, it needs to be run from multiple locations so that the true state of the target can be known. If a site shows down from Cleveland, but up from Bengaluru and Istanbul, then it’s not DOWN-down. It’s only down-ish (hey, I don’t make up these highly technical ter… Ok. I’m totally making them up. But I hope you go with it anyway. But I digress…)
Common approaches to multi-location testing
For many monitoring tools, “multiple locations” is accomplished either by:
- Asking you, the user, to install Yet-Another-Damn-Agent on systems you own and maintain to run those tests from within your locations This still doesn’t answer the question of whether your users – who are most likely NOT in your corporate data centers – can get to the application.
- Putting agents in the three I mean five I mean however many cloud providers are in operation today and monitoring from there. Once again, unless your users are also inside those cloud locations, this is only partially informative.
What makes Catchpoint different?
Catchpoint has 3,000 (that’s THREE-FREAKING-THOUSAND, for those who prefer their numbers in bold-underlined-all-caps) locations. Literally no other monitoring solution has that kind of coverage. And more than that, the locations are “real”. Meaning that they extend beyond just the usual suspects of cloud-and-colo. We have multiple endpoints embedded in every major ISP across the globe. And hundreds of “last mile” locations, which are as close to your house as we can get without having a device stuck in your underwear drawer.
This is such a critical difference that I thought it deserved its own section. And it applies not only to traceroute, but to every test in Catchpoint’s suite of solutions.
Is setting up a traceroute test really worth it?
Yes! If there’s one thing you take away from this blog, it’s that setting up a traceroute test is both easy and impactful. Easy in the sense that there aren’t that many steps to get one stood up, and impactful because – as old… I mean “revered” as traceroute is, it still has a lot of relevance and importance in terms of helping you understand how your applications, networks, and infrastructure is performing.
Dive deeper
- Now that you’ve got your test up and running, check out our comprehensive guide on how to read a traceroute for practical tips, real-world examples, and common pitfalls to avoid.
This is some text inside of a div block.
