Howard Beader, 00:05 - 08:07

Hello, everyone, and welcome. Thank you all for taking the time to join us today.

We have lots of great new capabilities to share with you. It's going to be hopefully a very exciting launch event, talking about what's new here at Catchpoint.

So, wherever you are in the world, thank you for joining. We have on the right side, I believe, of your screens, there is chat capability.

Please say hello. Let us know where you're from.

Let us know that you're there. Feel free to ask any sort of questions that you have throughout.

We've got a phenomenal panel of folks ready to answer all of your questions. There is also a q and a tab that you can leverage as well, over there on the right to ask questions, and we will try and get to all of the questions that have been asked.

So with that, you're probably wondering who's going to be presenting to you all today. We've got a phenomenal panel of speakers.

We have our chief product officer, Matt Izzo, and Matt will say hello shortly. We have our head of solutions engineering, Bob Ruggiero.

And then there is, of course, me, Howard Beader. I lead product marketing here.

So definitely say hello. Don't be shy.

Let's all, we are a relatively small IPM community at this point that is growing rapidly, and we definitely want to support you all. So feel free to jump in with questions.

So we like to talk about Catchpoint as it is the organization the Internet relies on. We are supporting many of the largest organizations in the world, ensuring the resilience of their digital experience.

Hopefully, we're doing so for your organization already. And if not, we definitely would like to help.

What we're going to cover today is we're going to be talking about our IPM platform vision. And the IPM is Internet performance monitoring.

We're going to be talking about optimizing web experience, automating all things around IPM, and we're going to be talking about how we're leveraging AI to simplify your Internet performance monitoring. Now, Catchpoint does a number of releases throughout the year.

We do somewhere around 8 to 10 releases a year. And, what we're going to be talking about in this webinar are our releases from LION in May through LYNX as of yesterday.

You're going to hear about all these phenomenal new capabilities. So here at Catchpoint, we talk about monitoring what matters, which is that Internet stack, being able to monitor from where it matters for you, where your employees are, we, our customers, are we, our partners, are all the way around the world leveraging our observability network, ultimately, to get to the answers faster.

Right? We want to be able to shorten the time it takes to identify the issues so that the issues can be solved before they become an issue for your business. And, of course, what we focus on is this Internet stack and the experiences.

And this is just getting more and more complex as time goes on, and the stack is made up of everything from the network components to the protocols, cloud services, Internet core, different media, etcetera. And that's where Internet performance monitoring really comes from.

It's about providing full visibility into that stack, looking at it so that you can catch issues across the Internet stack for your customers, for your workflows, for your applications and network, for your APIs, and for your website experiences. Now what we're doing with Catchpoint and what you're going to hear about is we're monitoring really from the end user, now all the way down into the code with the addition of tracing.

We believe this is something we're one of the only folks to be able to do all the way through the Internet stat, and it's something that we're going to share with you today. So how many of you have challenges ensuring the resilience of your applications? Right? All of your applications rely on the Internet.

There's 100s, if not 1000s of dependencies, and yet we're all still stuck with too many incidents, too many war rooms. Maybe you don't have the visibility you need for the Internet stack.

You just have visibility of the application stack. And you can't just wait to rely on status pages from the different cloud vendors.

Perhaps, you know, you need to know right now, which is typically the case when there's an issue. What we're doing is we are launching a new turnkey solution called App Assure.

App Assure is about providing resilience for your key applications. It's bringing together the really the best, and some of the newest capabilities across Catchpoint, to provide that resilience and insights and help you achieve SLOs and help you reduce NTTD and MTTR, ultimately, hopefully, eliminating, those some of those war rooms.

We want to help you ensure that there's less finger pointing among all your teams. What we're doing with App Assure is we've crafted, really, 2 different packages.

It's no installs, no agents, no distractions, really focused around one app or a website, and it brings together Sonar and Stack Map that you're going to hear about today. It includes our onboarding.

It includes a set of recommended tests, and this gives you that quick visibility to be able to monitor your key applications very, very quickly at a very nice price point. This is something we're sure many of you are going to be interested in.

We'd love to talk to you about this. Definitely an exciting new offer from Catchpoint.

Alright. And with that, Matt, do you want to.

Matt Izzo, 08:07 - 23:43

Sure. Absolutely.

Thank you, Howard. I am Matt Izzo.

I'm chief product officer here at Catchpoint. Perhaps you've received email release notes from me.

That's a huge team effort, so they come from me, but many people are involved in that. Obviously, not just assembling and sending those out, but also all the people who work on the features here.

And you might have noticed you just got a set of release notes yesterday because we did have a release. If you recall the slide that Howard showed earlier, the previous releases that we've had since our last launch webinar, which I think was in May.

So, the most recent release was links, which was yesterday. And our theme for this year, if you haven't figured it out, is fast cats.

Anyway, if you look at your previous release notes, you'll see all of what we've done individually. But as Howard said, we have one main platform, and that's one of the things that we focus on.

We think data is very important. Pulling all the information together, pulling that data together, that is commonly accessible, whether it's RUM data or synthetic data or now tracing, wherever your data is coming from, being able to analyze it, slice and dice that data in the various tools and capabilities that we have.

That's what we focus on all on one platform. Let's dive in and take a look at some of the things that we've done.

Some of these are big features. Some of these are small features and capabilities.

I hope that you find some things that really address some of the needs and interests that you have and make yours, make your effort at your job more valuable, and make your lives easier as well. So a lot of what we do really comes from a monitoring footprint, and we do operate the largest active synthetic monitoring, testing network, really, in the industry, and that continues to grow.

If you saw a chart like this or the numbers that we had even just a few months ago, they were a lot smaller. Not a lot smaller, but smaller by these amounts.

Since the last release, we've added 83 new nodes in 37 new cities, 21 new ISPs, 12 new countries, and 43 new BGP peers. We're constantly growing, and this gives us close to where we're coming in on, 3,000 vantage points.

We're, you know, at 2832. I would not be surprised if the next launch webinar that we give next spring, if we don't hit that 3,000 point just because it does continue to grow.

And other than the cloud nodes that that you see on the left, our the bulk of our locations, our monitoring locations, our backbone nodes, backbone locations, last mile, wireless, and so forth. These are all real locations.

They're on dedicated ISPs, not, you know, 3rd and 4th tier ISPs, but top tier ISPs. Basically, you're testing, customer experience from where your customers are, and your customers are monitoring from real locations.

They're on their laptops or their mobile devices, and they're getting access to services from, you know, the ISPs that that you know. Certainly, your services may be in the cloud.

They probably are. You're probably using multi cloud.

Testing to and from and between clouds, that's certainly very important. But the reason why I say this is because this is very important to us.

If you're monitoring the customer experience, the experience that your customers are having, you need to do that from real locations, where they are. Otherwise, it's kind of like, I always think of having a, an earthquake detector in Kansas.

See, there is someone here from Kansas City. If you have an earthquake detector in Kansas City for people who live in California, how helpful is that? Or a tsunami detector in the middle of the US or in the middle of, China or Europe, for people who live in Japan.

It's not really very helpful. Anyway, it seems simple.

We think it's very important, but it is kind of surprising that there are still a lot of solutions out there where you're managing your monitoring from places where it doesn't really matter, to be honest.  

Enterprise nodes, these are Catchpoint synthetic testing nodes that you deploy in your own environment.

There are thousands of these deployed in all kinds of locations, last mile, point of sale, data centers, branch offices, and so forth, all kinds of locations. We've even had companies deploy enterprise nodes in corporate jets and campus buses and things like that.

And there are 2 types that we offer, the standard, which is really the full does the full set of synthetic testing with all test types and so forth that we offer, and, a light node, that we had rolled out in the past year that's that is GA. And the light node really focuses more on, network-oriented testing, things like ping and traceroute and object tests and so forth.

What's new is, for the standard enterprise nodes, we've added Red Hat 9 and Ubuntu 22. I know there are customers out there and users who have asked us for those and been waiting for those.

So those have been rolled out recently. We're very happy to be able to do that.

And then for enterprise light, we now support Arm architecture. So, deploying this would be for, you know, point of sale, branch offices.

Maybe you're not doing heavy duty transaction web testing from those locations, but making sure that employees at that location, that services at that location are actually working and the network is up, and performing well, that's really important. So being able to deploy these in you know, with Raspberry Pi and other similar nodes, deployable also on network devices like Cisco, routers, and switches.

That's those are common deployments, and those are some of the things that that we have deployed. One other thing I missed, I just see on the slide, of course, easily remove node instances.

This is a rather simple but useful functionality that we have recently added. The reason this is important is because enterprise nodes are extremely scalable.

You can have multiple instances of a virtual machine, a node agent that combined make up the entire enterprise node. So, you can easily add instances, just to scale up and just making it easier to remove these instances is an obvious capability.

Node to node test is really great for testing your internal network. Speaking of networks and enterprise nodes, by popular demand, we have updated our node-to-node test to include 2 new things.

One is testing at 1 minute frequency. If you need to test faster than 1 minute, especially network testing.

We do offer continuous ping testing, which is available at subsecond, frequencies. I think 200 milliseconds, up to a second.

The other thing that we've added, also a popular request, is the ability to run node to node mesh tests between your enterprise nodes and the Catchpoint public nodes. So that is, for example, between, your enterprise nodes and backbone nodes, between last mile cloud nodes, and so forth.

You can't run a node-to-node mesh test between just backbone nodes. That's not a use case that is particularly useful in most cases, but you can run between cloud nodes and any other node type.

That is useful because just like with your enterprise nodes, if your services and your solutions are deployed across multiple clouds, that's an important use case. So, node to node mesh testing between your enterprise nodes, other nodes in the network, as well as between cloud and any anything else is relatively new and added within, the last few releases.

We've updated network monitoring with the ability to see more detailed information about the cloud networks that your services are going through, that you are testing. So, for example, if your traceroute is traversing a cloud network, you can now see the service name, which you can see in the, the pop up, the hover card there.

In this case, it's AWS, AWS US East 1. If you're familiar with cloud networks and regions, you know, you'll recognize that.

You'll see the IP prefix, the region, network border group, if that information is available. We'll also tell you if that information is actually verified by the cloud provider.

So that's very helpful. All in all, this type of thing is important just to troubleshoot your network when traversing the cloud, so we think this will help a lot.

There are some additional network path enhancements that you'll see. I would encourage you to look at the release notes from yesterday.

This stuff is basically hot off the press or hot from our engineering and testing and QA environments deployed, and these capabilities are really brand new. This also from the links released just yesterday.

Endpoint monitoring. So endpoint, this is what enables you to really test, from remote employee devices so you can ensure that your remote employees, because we're still in a hybrid world.

I'm here at the Catchpoint New York office, but many of us work from home or from other offices distributed around the globe, really, and making sure that employees have access to and good performance for the applications that they need. That's critical.

If you're in sales and you can't get access to Salesforce, you're in trouble, and so forth. So many examples of that.

So some of the new capabilities, just the ability to set alerts on specific processes, that are running on a device, that's important. The ability to get additional, alert information, from the endpoint just overall making it easier, and faster just to identify, well, which endpoint is or endpoints are having trouble when alerts are triggered, and additional metrics from the endpoint itself in the alert webhook.

I'll mention something about webhooks later, but many, many customers of Catchpoint, users of Catchpoint use the alert webhook to get live alerts, as they happen and forward them to other systems that they use. So just providing additional metrics about endpoint alerts is very helpful.

I think that includes the label CPU, memory utilization, Wi Fi, and call control call quality metrics, in that case for endpoint. So we're very happy to be able to enable that.

Duplicate dashboards, you know, it's a pretty simple feature, maybe obvious, but what we found was that there are a lot of companies that were creating an individual dashboard board for 1 service or one product in Catchpoint, maybe a set of dashboards, and then they were manually replicating that for all the other services that we that they were monitoring and that became just, you know, as a product manager at heart, you know, one of those things, we want to make that easier. So just being able to click on a dashboard and duplicate dashboards, and somebody used duplicate dashboards yesterday.

I'm glad, Scott. Very happy to be able to, you know, provide that.

That's certainly something I would want. And that works for any of the custom dashboards, whether it's Stack Map or EarthView for RUM or just your regular custom dashboards.

Another feature, speaking of things that people ask for is a global audit log. Global audit log, it's not just changelog.

Changelog is very detailed; you're looking at a test or a dashboard and you want to see what the change log is specifically for this item. Global audit log, often used just out of corporate for security and accountability.

This gives you the ability just to see who did what and when. So it's across your entire client.

It's pretty easy to access. It's available in the charm bar.

It's that top menu bar in Catchpoint, and you can see it right there. It'll be new as of as of yesterday.

It was just released out in links. So, hopefully, that will be useful to you and maybe get some, if you're being hounded by your security team or your auditor for that kind of information, well, now it's available.

Alright. Let's take a minute to talk about it just from a web experience perspective.

A lot of the things I just spoke about really are platform wide. So this is from the catch point 2024 reliability survey.

We've been doing these reliability surveys for a while, and, overall, you can see really broad agreement that, well, performance is at least as important as availability. It seems obvious.

Right? Every time I see slow is the new down, you know, I've been seeing this. We've been saying it probably for years.

Slow is like the old new down. If you're not worrying about performance, you're only worrying about availability.

You're missing a lot. But, Howard, do you want to say anything about the reliability survey that we released for this particular chart?

Howard Beader, 23:43 - 24:43

Yes. Thanks, Matt.

Yeah. So the reliability survey, so we've been doing the SRE survey for 6 or 7 years now.

Working on the next one right now. The reliability survey was the first and this is the 1st year that we've released that.

We'll make that available. We'll drop the link into the chat, but definitely a great document.

If you've not had a chance to take a look at it, definitely do so. We believe it's something that just some of the stats and findings in there can help you, you all, you know, justify your business cases, and, you know, support some of the decisions that you're all making moving forward to improve, you know, the overall reliability and resilience of your solutions.

Back to you, Matt.

Matt Izzo, 24:43 - 31:59

Thanks. Yeah.

Great. It's always good to see justification or just support for what you probably have been thinking or believe in, strongly already.

Otherwise, you wouldn't be here. And, yeah, thanks for correcting me.

This is the 1st reliability survey. The SRE survey every year is great, by the way.

Always keep your eye out for that. I like it.

And Howard's posted a link. Thank you.

So let's talk about webpagetest. We have been working, pretty diligently, over this this this past year to bring web page test fully and natively into the Catchpoint portal, and that that that process is virtually complete.

We've done a lot in the last few releases. In terms of web page test as an instant test in Catchpoint, opportunities and experiments, experiments are those really cool, no code, the no code ability to try variations and changes in your web page, to see what the performance is without developing it and rolling it out.

So you can well, I won't go into it now because we could spend a lot of time on it. It's a very cool feature but check that out in webpagetest.

It is a very cool capability. Again, no code.

Change your website. See what the impact is before actually coding in that change.

Records Compare is pretty helpful. If you need to compare the records of a couple of different test runs, that's important.

The ability to see the whole video in the waterfall is very helpful. See that in in sort of a live looking manner.

Carbon control - there's continuing interest in what's the environmental impact of your website is. Kind of debatable exactly how to calculate that.

There are a handful of different ways, and we have been monitoring and contributing to the industry and how best to do that, but especially, it is great to be able to see comparison. Is what you're doing helping or hurting, compared to the last release or the releases before? So that's a a helpful thing, and in some parts of the world, this type of this type of, capability, and accountability is becoming required.

Supporting additional locations and custom metrics, you know, all in, web page test, Catchpoint web page test in the Catchpoint portal. Some of the benefits, you know, why enable web page test in the Catchpoint portal when you can access it from web page test dot org, also a Catchpoint website? Well, the benefits really are because you're using the same platform, getting internal alignment, between things like the web developers, SREs, front end developers, and so forth.

There are 100000 users of webpagetest. If you're using Catchpoint, synthetic testing or RUM, tracing, or any of the other capabilities that that we offer, odds are very, very high that people in your organization are already using webpagetest.

Having a common place to look at data, to compare data, as well as use some of the other capabilities that we have, like dashboards and smartboards and experience score and run SLOs, Kavi dashboard now, as well as well as, you know, using RUM. A lot of people who use web page test are interested in RUM data, or tracing.

So using that from a common platform to us seemed like, pretty much of a no brainer. Speaking of RUM, we've made a lot of enhancements to RUM as well.

This is from the new SMART Board, which is an all-in-one dashboard that we use. I use it basically to identify and troubleshoot issues.

This is a preview. You can see in the upper corner or in your own portal.

You do enable it. We're really, it's only preview so that we can make sure that it has the functionality and the data and the information that you need.

And, really, like with anything with Catchpoint, if you have requests or recommendations, please let us know because that's really the purpose, for what we're trying to do, to provide tools and capabilities that make your jobs, more valuable in your company, make your contribution to your company more valuable and your lives easier. We've also added frustration metrics.

So, rage clicks, dead clicks, errors, and thrashing cur cursor, that's always useful to track, for obvious reasons. Interaction to next pane.

INP is a replacement is a Core Web Vital replacement for first input delay. So, basically, this indicates how long it took for your web page pinpoint, and that's in, that is in SMART Board, and just supported by RUM and Catchpoint in general.

Just a teaser for coming soon. We are, in active development, on an open telemetry based mobile RUM product.

If you are interested in that, if you we're we are looking for some companies to do some usability testing on the SMART Board for that as well. If you're interested, let us know.

But that is something that we're really excited about and, hoping we'll we are planning to roll that out soon given the pace that that we are able to build things. That, that should be pretty soon.

So, another result from our reliability survey, on service level objectives. You can see this is the second item up there.

The second you know, should your organization prioritize? What should you be prioritizing over the 12 next 12 months? SRE, an obvious one. Service level and experience level objectives.

So, Howard, anything else to say on the survey?

Howard Beader, 31:59 - 32:37

Yeah. I think these results, pretty much speak for themselves.

Right? This is something that everybody's recognizing that there's a huge need. SREs, right up there, and we'll see more details on SRE in both the Google DORA report, which comes out shortly in, our own SRE report.

But service level, objectives, XLOs are something that folks really need to be focusing on now, and that's what we're hearing, that's what we're seeing.  

Matt Izzo, 32:37 - 50:47

Great. So let's talk about SLOs and XLOs.

You guys probably know this, so you're not going to spend much time on it. You know, the SLA, that's the agreement.

We offer 99. 995 whatever availability, and if we fail that, we will give you some of your money back kind of thing.

The SLO is the actual objective, you know, 99. 9 whatever, and the indicator is the actual metric that you're that you're measuring.

So SLO versus XLO, if the service level objective is the performance goal for a service, really, an XLO I think of an XLO as same thing as an SLO, except it's measuring that, in a way that that, represents what the user experiences. So in Catchpoint, for simplicity, we call everything an SLO.

But if you are monitoring and you're tracking an SLO and you're using data that's collected from backbone or last mile wireless nodes, that's an XLO because you're testing in line with the delivery of service to your customers. That's why you're doing it.

So, just, you know, that's SLO versus XLO. Don't get hung up on it.

But XLO is really the terminology that I see more and more people using for what that's worth. What we've done is, since our last webinar, we've added several new performance metrics for creating XLOs.

These are things like Core Web Vitals, cumulative layout shift, First Contentful Paint, and so forth. Some of them are a mouthful.

Time to interactive, response time DNS time, not a Core Web Vital obvious, but, you know, is it helpful to have an XLO on your DNS time? Does DNS ever DNS never goes down. DNS is never the fault.

Right? So it it's not always the fault, but it's often the first thing to look at. Wait time, test time, and, of course, well, those are in addition to what we've already had, which is test time and availability.

So, again, I'm a big fan of SLOs and XLOs. Even if you're not reporting them to be part of an SLA that your customer gets or reporting them as an SLO to your boss or your executive, this gives you something to measure against.

There are recommendations for what some of these metrics should be, which is very helpful. So this is a burndown chart, which if you're not familiar with it, shows you the performance trend of your XLO or SLO, whether you're on track to meet it or not.

If you're above the dashed line, you're generally are in good shape to meet your SLO or XLO, and if you're below it, well, you're trending in in the wrong way. And on the left is basically how many minutes of violation can you support.

So if the line goes down to 0, you failed. This is a 3-month view of this XLO, so, hence, you can see the 3 months, but we also support weekly and daily views.

Right now, they're looking pretty good as of August. This is a popular movie theater website.

I won't tell you who it is, but it, you know, it could you know who those sites are. Right? Movies.com and Fandango and AMC Theater and so forth. So it's one of those movie sites, and, you know, they're at risk.

What do you think? Do you think they're going to meet their XLO or not? This is largest contentful paint. Google recommends 2 and a half seconds or less for the 75th percentile.

This XLO, I wanted to be a little generous, and I made it, I think it was, 4 seconds. Movie sites often have big images on it.

Just trying to be not so harsh on them. Well, looking at that exact same site and comparing availability versus performance, most SLOs are available, but that just doesn't give you the full picture.

Right? If you look on the left, the SLO here is 9995. Great news.

Services I'm sorry. 995.

Yeah. Service is fantastic.

100% availability. People must love this service.

It's great. On the right, it's that same, XLO on largest Contentful Paint, the same one I showed before, except now it's after the quarter end.

You see, they started to trend better, but they didn't make it. So what does that mean? That means that not just you're failing the XLO, which is great at least internally, they should be looking at this, but your customers are getting poor performance.

They're waiting for the large images to load, for the page to be interactive maybe.

I've got XLOs on the same on those other metrics as well. Time to interactive, frankly, it's even worse.

But, yeah, really, at this point, you're hoping customers want to see that movie so bad and buy the ticket from you that they're not going to bounce. But in a lot of cases, you know, if you're selling something online or there are a lot of cases people are just going to bounce.

They're not going to wait for that. So, that's SLOs.

Again, I would just personally recommend that even if you're not using SLOs and XLOs, for your customers and, you know, your executives. Use them internally.

These are available, and these are free to use. You can create XLOs and Catchpoint on the tests that you have.

So your tests consume points, the XLOs, they don't consume any other points. This is just, an additional way to view your data, the data that you collect.

Switching to tracing. So earlier this year, we rolled out an OpenTelemetry based tracing product.

You know, as you guessed it, I mentioned RUM. We're very big on OpenTelemetry.

We think that it's really helpful for our customers. We hear many companies tell us you have to be OpenTelemetry, compliant or support OpenTelemetry, and that's that is important to us too, too.

We often try to answer with Catchpoint the reason why people use us, and I've heard many customers say the question that they have often is, is it us or someone else when there's a problem? So if the problem is somewhere else, we will do a fantastic job in Catchpoint of showing you where. Is it that DNS problem? Is you know, do you need a better time to interactive, or is your traffic being routed through another country, where it shouldn't be because your CDN is misconfigured? We do a great job of that.

If the problem is you, you want to drill down really directly from your synthetic test. That's something that, you know, we have companies doing today.

Tracing is our answer to be able to provide that, natively right in Catchpoint, the ability to just go from your synthetic test and drill down into your distributed applications and even down to the code level. It's done with, OpenTelemetry, and in some in the this is something that we have rolled out.

I think we spoke about it at the last release webinar in May. Some of the capabilities that we've rolled out recently are things like what you're seeing here, this overview, system level dashboard.

You can see the various tracing systems on your left. And anyone that you're using, you can click in and navigate.

And this is a flow view. You also we also have a cluster view and, you know, the standard things that you would expect from a tracing application.

But right here, in in, Catchpoint, we added a system and service health score. This application, well, it's a 0, so that's not good.

And, as well as just the ability to use control center, which you would be familiar with for RUM and for synthetic tests, using library and all those other capabilities, the control center helps, just to be able to set this up. Our goal with tracing is to provide something that is simple to use, simple to implement and adopt.

Pricing is very, very simple, so it's not, you know, how many gigabit hours of data you're storing. You know, we don't, you know, as the head of product, I certainly don't want any customers to be hit with an $80,000 surprise bill because they're using more data than they experienced, so we don't charge based on that.

And, yeah, it's a little bit of a commercial for this. But if you're interested in this, please let us know because that interest is growing, and we're still looking for feedback on any early product.

It is fully GA, and we are continuing to roll out capabilities. So, let us know if that's something that you're interested in.

Now let's change topics a little bit. A lot of companies already use Catchpoint in their CICD process.

If you're on this call, you probably are doing this too, directly or indirectly, you know, setting up your service, making changes, testing those changes. Most problems occur with a change even, you know, still today, whether that change is manual or automated.

So just having your monitoring strategy linked in with your deployment strategy is an obvious thing and certainly not, not new, so I won't really walk through that slide. We offer multiple APIs, multiple ways of accessing Catchpoint information, and most of these are used very, very frequently and heavily by our customer base.

So, obviously, there's the REST API. We have been migrating from v 1 to v 2, v 3, which is offers a lot of improvements, in addition to the fact that to the API limits per hour, per day, we don't count any API requests that have to do with creating or, configuring or requesting configuration about your tests, for example.

That's the bulk of what people do. So that is a big improvement just by that alone.

In general, the v 2 and v 3 API capabilities far outstrip what can be done with v 1. We've got their real time data push as well, the data webhook, heavily used for getting that data in basically a stream.

Alert webhook, similar. When alerts are created, they get sent out.

Alert webhook is probably the most commonly used webhook, especially for a lot of integrations, sending alert information to other systems, and so forth. Think for time, I'll speed this up.

Playwright and Puppeteer, you know, this is Playwright by Microsoft and Puppeteer by Google. This is where the industry is as far as and heading, as far as browser transaction testing.

Both of these are GA. They're cross browser functional, capabilities, so Edge and Chrome, for example, are supported today.

They handle pop ups and multiple tabs. That's something that we offer today with Playwright, and Puppeteer.

Client certificates, DNS override and request overrides We have added so some of the capabilities that we've had in our Selenium based Chrome testing, making sure that all of those are in Playwright and Puppeteer just because, again, that's where the industry is heading. Plus, we've added the ability to convert simple test types, for example, from Chrome to Playwright.

That's in the 3-dot menu in Control Center. If you click on a test and you see convert, you can convert that to a different type.

And, we are working on an AI based tool, that will convert Selenium scripts, as well. So I'm excited for that to be coming out.

Speaking of AI, a lot of what we've done you know, I mentioned, the script converter. All the talk in AI is on is on generative AI and chatbots.

Most of our customers, virtually all of our customers, have told us that what's really important to them is the data. So a lot of what we've been focusing on are things like massive correlation and trend shift detection and trend shift correlation and things like that.

Internet stack map is, in a sense, a massive correlation engine behind a dashboard that shows you a live system level view of your service. This case, that's the service on the top, and the health of your service and its relationship, its dependency on other services like DNS, like CDN, Adware, MarTech services, your back end services as well, the dependency that you have on them.

If those go down, are they correlated to your service being down? That's what that is what Internet stack map does. It is integrated with sonar, so anything that we monitor and detect with our sonar product as well is automatically reflected in here.

This is a this is an amazing capability. I could spend the entire time just talking and demonstrating that, but we'll give Bob a minute to show you.

So, this is a big part of that. And some of the capabilities that we've added, well, just not just correlating, your regular test information like web, an object, so forth tests, but network performance as well because you want to see, you know, how does the how does how do changes in the network, or network problems, how do they impact your service? In addition, things like just filtering on on your geolocations, is an obvious capability and as well as getting data from API test because a lot of services, especially mobile services, rely on API testing.

Also, fully functional dashboard, drill in, slice and dice data, and so forth. I mentioned sonar. So you can see what SONAR is.

We detect outages around the world, as well as network outages and network impacts. The ability to filter SONAR to a given stack map is important because if you're using stack map, you probably want to see what are the outages for the services in my particular stack map.

You may have multiple stack maps. What are the outages that are detected by sonar for those services? And we show that here.

This is a view of sonar filtered to a given stack map. This is for this is a previous moment in time.

That's why services are green. So, if there was an outage, but that outage has been corrected, that service has recovered, you'll see that as recent outages, and you'll see that, as green.

If there are multiple outages, you'll see a number in the circle. And any service that is in your stack map but doesn't have an outage, we show that below in in those services that are not, that are not affected.

As well as just overall coloring in a darker gray, the services the regions that, are relative to that specific stack map. So if you have a stack map that is only concerned with service in Europe or Asia or, in in this case, North America, that area of the of the world will be color coded correspondingly.

With that, let me turn it over to Bob. You've heard me speak enough, maybe too much, and Bob can give a demo.

Bob Ruggiero, 50:47 - 56:19

Awesome. Thank you, Matt.

And, I will bring up my screen here. Hopefully, everyone can see this.

So great. So, in the next 5 minutes or so, what I wanted to do was introduce you to one of the new programs and services that I am very excited about, which is App Assure.

So as we mentioned earlier, my name is Bob Ruggiero. I'm the director of the solution engineering team here at Catchpoint.

And, this new program is really the goal here is to provide a faster time to value, speed up the time to value, by providing opportunities that allow you to improve your performance, improve the availability of your most business critical applications, and in the end, make it more resilient. So as Howard mentioned earlier, App Assure is really a turnkey solution, meaning that there's nothing that you need to install.

There's no training that needs to be facilitated for your teams. All you have to do is provide us with the application that you care about.

And that's a matter of, you know, giving us a URL, maybe a set of workflows that typical users would go through in that application. So if it's a retail app, it might be adding a product to the cart, checking out, things like that.

If it's, you know, an application or a developer centric, type site where people are checking in and checking out code, tell us what those workflows are, and we'll build the test for it. If it's a banking application, you might be withdrawing, transferring funds, things like that.

It doesn't matter what the app is from manufacturing to insurance claims. Tell us what the URL is.

Tell us what the workflows are, and our team of experts will go ahead and literally within hours, go out, create a set of tests that provide that complete visibility into the application. So we'll develop tests that target, you know, specific APIs if there's APIs that are used within the app.

We'll set up tests that validate the DNS services. Matt mentioned earlier, that's always the first thing that that you want to look at.

We will do workflow type checks. How long did it take for someone to log into the app? How long did it take for them to check out? How long did it take for them to perform a search? Things like that.

We'll do validations of your SSL certificates. You know, when are they going to expire? And notify you, you know, as that expiration date gets closer.

We'll do network level testing. So the goal and the point here is that, like I said earlier, in a matter of hours, these tests will be enabled based on best practices, proven methodologies that our team of experts have driven value with across a lot of our customers already, we'll get that set up enabled so you can start seeing the insights and the value from that telemetry and from that data.

And one of the visualizations that we'll use to surface up those insights is Stack Map. So as Matt mentioned earlier, it's a visual representation of all of the services and dependencies that drive your application.

Catchpoint automatically discovers these services based on the test that we've enabled. So whether that be your DNS providers, your CDNs, any third-party services like tag managers or social media, entries, advertising services, APIs, all the way to your back-end cloud providers, we're going to automatically flag cases where a particular service is degraded or just flat out has failed.

And then that gives you the insight as to, okay, who do we need to get involved to further troubleshoot this problem and not necessarily have to get into a war room situation where everyone is on the phone pointing fingers as to, you know, who's going to own that problem. We're going to do a lot of that analysis for you, but you also have the ability to click into a degraded service, look at the records that have caused that failure, and immediately within 2 to 3 clicks, have the data, have the information that we need so we know why a particular service is failing.

And in this particular case, we have requests here, API requests that are going out to this, rest API called events. Backtrace it and as we see, that's resulted in a 401.

So that service is degraded. It's impacting our user experience.

We now immediately know what the problem is and we can begin to investigate. So it's really that simplicity, that faster time to value that, you know, we're going to provide through this App Assure program.

If anyone is interested, please let us know. Happy to discuss it more.

I know I went through that quickly, but hopefully that, that provides some, some initial insights into the service. With that, I will stop sharing myself and will give it back to Howard for any questions.  

‍

Howard Beader, 56:19 - 57:26

Awesome. Thank you, Bob.

Great demo. Matt, great content as always.