.png?width=200&height=59&name=IPTellogo-byline-2020-dark-v2-pnd-optimised-500%20(1).png "IPTellogo-byline-2020-dark-v2-pnd-optimised-500 (1)")
Internal billing systems, remote sites, an online store and a stack of SaaS subscriptions — most businesses depend on all of them at once, over networks they only partly control. In this blog, we'll walk through how our application dependency monitoring service runs day to day, from scoping the tests to the alerts, reports and reviews that follow.
Scope: Deciding What to Test
Every engagement starts with scope: which applications and sites matter most, and what a problem with each would cost the business. The list might include a remote site, a customer-facing website, an internal billing application or a SaaS platform. Getting this right first keeps the test plan focused and licence use sensible.
We ask simple questions. Who uses it? From where? What does slow look like to them, and how quickly does someone need to know?
Scope then sets the depth of testing. Some targets only need a reachability and latency check; others justify a scripted transaction that logs in and completes a task, just as a user would.
It's a balancing act. More tests, run more often from more places, give finer detail but use more ThousandEyes units, so we help you find the point where the insight justifies the spend.
ThousandEyes: Agents and Test Types
The tests run on Cisco ThousandEyes. Enterprise agents sit inside your network at the sites that matter, cloud agents test from the outside in, and endpoint agents can measure from users' own devices. Our engineers build and maintain every test as part of our managed services.
Each test type answers a different question. Network tests trace the path hop by hop, HTTP and page-load tests time the web service, DNS tests confirm names resolve correctly, and transaction tests step through a real user journey.
If you already hold ThousandEyes licences, we work within your account. If not, we can supply and manage the licensing for you.
Pro-Tip: Don't test only from head office. It usually has the best connectivity in the business, which makes it a poor stand-in for what branch and remote users actually experience.
AFOM: Agreeing What Good Looks Like
With tests running, we document an agreed form of measure (AFOM) with you. It sets the acceptable range for each test — latency, loss or response time, for example — and spells out what happens when a result falls outside it. Without that agreement, an alert is just a number on a screen.
Baselines shape the thresholds. A few weeks of normal running shows what each path really does, so the limits reflect your network rather than a generic default.
The AFOM also holds the alert and notification schema: who is told, how they're told and at what severity.
Alerting: From Threshold Breach to Ticket
When a test breaches its AFOM threshold, an alert opens a ticket in our service desk automatically, so an engineer is on it without anyone picking up the phone. The investigation is recorded from that first alert through to resolution, which makes the root-cause analysis straightforward to write.
The engineer's first job is to place the fault: inside your network, on an ISP path or with the application provider. ThousandEyes path data normally makes that call quick.
Your team sees the same picture. Highlight's live dashboard shows device health, performance and open incidents, and the customer portal holds tickets, planned changes and root-cause analyses.
Reporting: Reports and Service Reviews
Test results flow into regular reporting on how each application and path has performed, and into service reviews held quarterly or monthly depending on your managed service tier. Those reviews cover performance, incidents, changes, capacity and your technology roadmap, so the data turns into a plan.
This is where pinch points surface. A path that degrades at the same time each week, or a SaaS region that's consistently slower than the others, becomes a planning item instead of a recurring complaint.
We revisit the test plan itself, too. Applications come and go, so scope is reviewed rather than set and forgotten.
Application Dependency Monitoring: FAQs
What Does AFOM Stand For?
Agreed form of measure. It's the document we write with you that sets acceptable thresholds for each test and who is notified, and how, when a result falls outside them.
Can You Use Our Existing ThousandEyes Account?
Yes. If you already have ThousandEyes, we build and run the tests within your account. If you don't, we can supply and manage the licensing as part of the service.
Where Do I See the Results?
Day to day in the Highlight dashboard and the customer portal, then in the regular reports and service reviews, where we look at trends and decide what to change.
How Often Is the Test Plan Reviewed?
At each service review, and whenever you add an application, site or provider. Changes to tests go through the same change management process as the rest of your managed service.
Application Dependency Monitoring: Summary
Application dependency monitoring works because each step is deliberate: scope the applications and sites that matter, build the right ThousandEyes tests, agree thresholds in an AFOM, route breaches straight into the service desk and review the results on a regular rhythm. The outcome is a service that finds problems on paths you don't own and gives you the data to plan around them.
Need Help With Monitoring Your Applications?
If you'd like to see how this would run for your applications, start with our ThousandEyes option tool or the free 10-minute Build Your Business Case assessment, which recommends a service tier for your network. You can also read more about ThousandEyes at IPTel and our Cisco managed services.
If that's useful, make an enquiry or drop us a line at sales@iptel.com.au.