{"id":3291,"date":"2021-10-05T12:00:41","date_gmt":"2021-10-05T12:00:41","guid":{"rendered":"https:\/\/uptime.com\/blog\/?p=3291"},"modified":"2024-12-06T17:33:02","modified_gmt":"2024-12-06T17:33:02","slug":"dont-let-third-party-providers-bring-you-down","status":"publish","type":"post","link":"https:\/\/uptime.com\/blog\/dont-let-third-party-providers-bring-you-down","title":{"rendered":"Don’t Let Third-Party Providers Bring Your Uptime Down"},"content":{"rendered":"

False positives are sometimes real alerts in disguise. And they can contribute to some major downtime if you don\u2019t resolve them quickly. They can also put quite a strain on your resources trying to figure out why they\u2019re happening, and if you work with third-party providers, errors may be even harder to locate.<\/span><\/p>\n

Is it Real? Or Is it Fake?<\/span><\/h2>\n

You\u2019re minding your own business and suddenly you receive a few alerts. You do an initial investigation and verify that your site and systems are running as expected, but the alerts aren\u2019t stopping so you start to strategize. Your check is set to a standard 5-minute recurring interval, should you reduce it? Perhaps an increase in frequency will help you validate the error?\u00a0<\/span><\/p>\n

The answer may not lie in the interval.\u00a0<\/span><\/p>\n

Step 1: Ruling out False Positives<\/span><\/h3>\n

From a cursory glance, your site appears to be UP. So how do you confirm that you are in fact looking at a legitimate alert and not a false positive?<\/span><\/p>\n

The answer? Check your sensitivity.<\/span>\"\"<\/p>\n

Let\u2019s look at the anatomy of this\u00a0 check.\u00a0<\/strong><\/p>\n

Sensitivity<\/a> is connected to your check\u2019s locations. If you have configured 3 probe server locations for your check, then we recommend a sensitivity of 2 – 2 locations must fail for the check to be DOWN.\u00a0<\/span><\/p>\n

If you have 4 locations, we recommend a sensitivity of 3 and so on. This helps protect against network anomalies that may send your check DOWN.\u00a0<\/span><\/p>\n

You will also want to check the Number of Retries, or how many times the check will\u00a0 retry from each location before it is considered DOWN. If your sensitivity and retry settings aren\u2019t contributing to the likelihood of a false alert, it\u2019s time to drill down.<\/span><\/p>\n

<\/h3>\n

<\/h3>\n

Step 2: Dig into Real-Time Analysis<\/span><\/h3>\n

Your Alert Log and your check\u2019s Real-Time Analysis<\/a> will give you a lot of useful information that will help you authenticate your alert.\u00a0<\/span><\/p>\n

Let\u2019s say you had a Transaction Check fail at a Go To URL Command Step. It failed with a Navigation timeout error. When you review your real-time analysis you get a screenshot of the page and the step element for a visual verification of the incident as well as browser console data.\u00a0<\/span><\/p>\n

These details can help.\u00a0<\/span><\/p>\n

The Go To URL step expects the <\/span>Load event<\/span><\/a> to be fired after the entire page has loaded, including all dependent resources, stylesheets, and images. We know something prevented the load event from firing for at least 30 seconds. Even if the URL is up, something is affecting website performance and could trigger downtime.<\/span><\/p>\n

Step 3: Location, Location, Location<\/span><\/h3>\n

A quick way to validate your alert is to check how many of your locations went down. We assume at least 2 if you are following our best practices but are ALL your locations down? Or just the minimum sensitivity? Did they failing at the same time?\u00a0<\/span><\/p>\n

The more locations down, the more likely the alert is an actual issue. So now for the big money question. Your systems are fine. Everything is fine. So what\u2019s causing the downtime in your monitoring service?<\/span><\/p>\n

If it\u2019s not <\/span>Me, <\/span><\/i>and it\u2019s Not <\/span>You, <\/span><\/i>It Must Be <\/span>Them<\/span><\/i><\/h2>\n

\u200bDoes your company work with third-party providers? Ours does. Most companies do. Oftentimes functions like payment portals, apps, even contact forms are run by companies outside your infrastructure.\u00a0<\/span><\/p>\n

These companies have sites with transaction pathways, elements, and components that are not impervious to downtime. If something on their site goes down, it could affect your Uptime and your user experience.<\/span><\/p>\n

No Paper Trail<\/span><\/h3>\n

Third-party downtime can be challenging to spot within your own system because third-party assets likely aren\u2019t reporting to your system or being recorded in your logs.<\/span><\/p>\n

There are 2 Strategies to implement here to improve your visibility and enhance your alerting structure.\u00a0<\/span><\/p>\n

SLA Accountability<\/span><\/h3>\n

We\u2019ve <\/span>talked before<\/span><\/a> about the importance of creating Service License Agreement (SLA) reports and Public SLA pages to report accurately and transparently on your own SLA guarantee<\/a> or accountabilities.\u00a0<\/span><\/p>\n

Heck, we\u2019ve even configured fields to funnel SLA requirements straight from checks to our reporting feature. If you\u2019re taking SLA seriously on your end, you should expect the same of the providers that you contract with.\u00a0<\/span><\/p>\n