WEBVTT - Support Engineering Weekly (Aug 24-28, 2026)
00:00.000 --> 00:09.500
This is Support Engineering Weekly from the Support Engineering Blog. Technical conversations for engineers who troubleshoot, support, and operate Microsoft technologies.
00:09.800 --> 00:17.500
Imagine, right, you're walking into your living room, you flip the light switch on the wall, and instead of the lamp turning on, your neighbor's garage door randomly opens.
00:17.600 --> 00:20.200
Oh, and your toaster instantly catches on fire.
00:20.300 --> 00:27.200
Right. Yes, exactly. Your toaster just spontaneously combusts. I mean, in the real physical world, you would probably call an exorcist.
00:27.300 --> 00:28.700
You just run.
00:28.800 --> 00:29.500
Yeah.
00:29.600 --> 00:34.500
But you know, in the world of enterprise cloud architecture, they just call that a Tuesday.
00:34.600 --> 00:40.500
They really do, and that is the exact chaotic reality we are getting into today. So, welcome to the deep dive.
00:40.600 --> 00:42.000
Glad to be here.
00:42.100 --> 00:54.000
Today, we are exploring a highly detailed, honestly, incredibly revealing stack of internal Microsoft service health and Message Center reports, and we're looking at a very specific window of time here: August 24th through August 28th, 2026.
00:54.100 --> 01:00.500
Yeah, and just to set the stage for you listening, this isn't going to be like a dry list of tech outages or server logs.
01:00.600 --> 01:05.500
Oh, absolutely not. We are going to treat this stack of reports like a forensic investigation.
01:05.600 --> 01:11.800
Exactly. Because our mission today is to decode the hidden mechanisms of why things actually break in modern cloud platforms.
01:11.900 --> 01:18.500
Right. Uncovering the invisible, deeply interconnected dominoes of enterprise architecture. Because, well, whether you are an IT administrator whose literal job is keeping the lights on, or—
01:18.600 --> 01:24.000
Or you're just a professional sitting at your desk, you know, wondering why your Teams app is suddenly acting like it's possessed.
01:24.100 --> 01:31.000
Exactly. Understanding these hidden dependencies is the ultimate shortcut to being well-informed about the digital tools you rely on every single day.
01:31.100 --> 01:38.200
It really is. When you—uh, when you pull back the curtain on a platform like Microsoft 365, you start to realize that what looks like a single cohesive application on your screen—
01:38.300 --> 01:40.200
Right, like just a standard app.
01:40.300 --> 01:46.500
Yeah, it's actually this massive breathing ecosystem of microservices, identity claims, and, well, hidden data pipelines.
01:46.600 --> 01:53.000
Okay, let's unpack that ecosystem, because the first major incident from the reports perfectly illustrates this. It's what I call "the illusion of the front end."
01:53.100 --> 01:57.200
Oh, yeah. We always tend to assume that where we see the problem is where the problem actually lives.
01:57.300 --> 02:02.800
Right. But on August 27th and 28th, users ran into these massive walls with Microsoft Teams channels.
02:02.900 --> 02:05.800
Ah, the infamous Power Automate bottleneck.
02:05.900 --> 02:11.500
That's the one. Power Automate flows that were, uh, supposed to post automated messages into Teams channels just suddenly started failing.
02:11.600 --> 02:13.600
Just completely stops working.
02:13.700 --> 02:21.000
Yeah, and then cloud flows trying to post or reply with adaptive cards in Teams, those completely broke too. Users were getting hit with HTTP 429 or 500 errors.
02:21.100 --> 02:23.500
The messages just vanished into the void.
02:23.600 --> 02:28.000
Exactly. And naturally, if you're the user sitting there staring at your screen, you assume Microsoft Teams is broken.
02:28.100 --> 02:34.200
Right, because the symptom is in Teams, so the blame goes to Teams. But, uh, what's fascinating here is what those specific errors actually mean.
02:34.300 --> 02:35.800
Break that down for us.
02:35.900 --> 02:43.000
So, an HTTP 429 error essentially means "too many requests." I mean, it's the digital equivalent of a bouncer at a club saying, you know, "the building is at capacity."
02:43.100 --> 02:45.100
Right. Nobody else is getting in.
02:45.200 --> 02:52.500
Nobody. And a 500 error, that's an internal server error, which is basically the server just throwing its hands up in a total panic. It literally cannot process what you're asking it to do.
02:52.600 --> 03:00.000
Wow. And, you know, earlier you mentioned adaptive cards breaking. For anyone who isn't a developer, an adaptive card isn't just like a simple text message.
03:00.100 --> 03:01.400
No, not at all.
03:01.500 --> 03:07.500
It's those interactive mini-apps that pop up in a chat, right? Like, uh, an expense approval form where you can actually click "Approve" right inside the Teams channel.
03:07.600 --> 03:14.200
Yeah, and that interactive element is crucial here. Because when Power Automate tries to publish one of those adaptive cards into a Teams channel, it isn't just one standalone program tossing a file to another.
03:14.300 --> 03:16.400
It's way more complicated than that.
03:16.500 --> 03:22.000
Way more. It relies on a highly specific internal service dependency to render the interface, process the data, and finally publish that card.
03:22.100 --> 03:24.000
So it's a whole chain of events.
03:24.100 --> 03:29.500
Exactly. In the old days of on-premises software, if the messaging app was broken, it meant the messaging server was down. But today, it's a web.
03:29.600 --> 03:37.000
A massive web. And according to the incident report, there was this huge influx of service calls that completely exhausted the available resources in that specific dependency's infrastructure.
03:37.100 --> 03:39.000
So Teams was totally fine.
03:39.100 --> 03:43.000
Teams was not broken. The root cause had absolutely nothing to do with the Teams client.
03:43.100 --> 03:48.500
The infrastructure holding up that specific, you know, invisible bridge between Power Automate and Teams just buckled under the weight of the traffic.
03:48.600 --> 03:52.500
It's like—it's like yelling at the delivery driver on your porch because the restaurant's stove is broken.
03:52.600 --> 03:54.800
Yes! That is a perfect analogy.
03:54.900 --> 03:59.800
I mean, the symptom is standing right in front of you, but the actual failure is miles away in some back-end kitchen.
03:59.900 --> 04:05.500
And that perfectly captures why troubleshooting in the cloud requires an entirely different mindset today. You really have to trace the complete dependency chain.
04:05.600 --> 04:09.500
Because if an IT team just stared at the Teams admin console trying to fix this—
04:09.600 --> 04:14.500
They'd be staring at it forever. You have to look past the app where the error surfaced and interrogate all those hidden services feeding it.
04:14.600 --> 04:20.000
Okay, so if hidden dependencies are the engine, I think we have to ask what usually causes that engine to sputter in the first place?
04:20.100 --> 04:24.000
Right, and you would assume it's like malicious attacks, hackers, or some old hardware catching fire.
04:24.100 --> 04:28.000
Yeah, that's the classic assumption. But looking at this August 2026 window, the culprit is almost always, well, good intentions.
04:28.100 --> 04:30.800
Routine changes meant to improve the system.
04:30.900 --> 04:37.500
Exactly. The butterfly effect of routine software updates. Let me give you an example from the reports. Microsoft deployed an authorization configuration update, and it was meant to block users who didn't have active licenses.
04:37.600 --> 04:39.500
Which makes total logical sense.
04:39.600 --> 04:45.000
Right. Keep the unlicensed folks out of the system. But the update inadvertently locked out fully licensed, completely legitimate Teams users. Microsoft had to rapidly revert it.
04:45.100 --> 04:52.500
Which really exposes the fragility of entitlement logic. I mean, a tiny miscalculation in how the system checks a user's subscription status suddenly cascades into, you know, thousands of people getting locked out of their morning meetings.
04:52.600 --> 04:56.000
Just massive disruption from a tiny tweak. And then we have the SharePoint guest access incident.
04:56.100 --> 04:58.200
Oh, that one was a mess.
04:58.300 --> 05:07.500
Yeah. A newly deployed change interacted incredibly badly with something called the dynamic claims process. So these guest users who were already granted access via Microsoft 365 Groups were suddenly hitting this cold, dead AccessDenied.aspx page.
05:07.600 --> 05:09.500
Just completely locked out.
05:09.600 --> 05:16.800
Yeah. And the only workaround was for administrators to manually bypass the group and add those users directly to SharePoint members groups. So walk me through this. What actually is a dynamic claim? Because the users were definitely in the system.
05:16.900 --> 05:22.000
Right. So think of permissions in layers, right? The user has an identity in the overarching directory.
05:22.100 --> 05:23.200
Okay.
05:23.300 --> 05:27.500
And they belong to a specific group. But that group membership doesn't just magically open the door to a specific SharePoint site.
05:27.600 --> 05:28.800
It doesn't.
05:28.900 --> 05:34.500
No. The overarching directory has to hand the user a digital token, a claim, that SharePoint specifically understands. And that translation happens dynamically, on the fly.
05:34.600 --> 05:39.500
Oh, I see. So the directory is saying, "Hey, this person is cool," but SharePoint needs that translated into its own specific language.
05:39.600 --> 05:43.500
Precisely. And Microsoft deployed a change that basically disrupted that dynamic translation.
05:43.600 --> 05:46.000
So the identity was perfectly fine.
05:46.100 --> 05:51.500
The identity was fine, the group was fine, the SharePoint site was fine, but that invisible translator sitting right in the middle completely broke down.
05:51.600 --> 05:56.500
Wow. It's like the bouncer gave you a VIP wristband, but the bartender suddenly doesn't recognize the color.
05:56.600 --> 05:57.800
Exactly.
05:57.900 --> 06:02.800
But I want to push back on this for a second on how these things even make it into production. Let's look at another one: Microsoft Bookings.
06:02.900 --> 06:04.500
Okay, yeah.
06:04.600 --> 06:11.800
Users started seeing completely blank pages because of repeated timeouts from a deprecated KV cache lookup. Basically, they enabled a change to retire an old cache, and it took down the pages.
06:11.900 --> 06:13.200
Right.
06:13.300 --> 06:18.000
Now, if I'm an IT director looking at this, I'm thinking Microsoft is a massive tech giant with virtually unlimited resources.
06:18.100 --> 06:19.400
Sure.
06:19.500 --> 06:24.000
How does a cache update break a booking page? Don't they test this stuff in a sandbox before pushing it to millions of users?
06:24.100 --> 06:30.500
Trust me, every IT leader screams that exact question when their systems go down. But to understand how a cache deprecation brings down a page, we have to talk about technical debt.
06:30.600 --> 06:32.500
Okay, break that down for me.
06:32.600 --> 06:36.500
First, a KV cache stands for a Key-Value cache. It is essentially a high-speed digital dictionary.
06:36.600 --> 06:37.600
Okay.
06:37.700 --> 06:44.000
The system looks up a simple key, like, say, a user ID, and quickly gets the complex value associated with it, like their scheduling preferences. Think of it like a coat check.
06:44.100 --> 06:45.500
A coat check.
06:45.600 --> 06:48.500
Yeah. You hand them a simple ticket, they hand you your heavy winter coat.
06:48.600 --> 06:51.500
Okay, makes sense. So they decided to shut down an old coat check.
06:51.600 --> 06:55.200
Right. They deprecated it, meaning they told the system, "Hey, we're retiring this, stop using it."
06:55.300 --> 06:56.500
Okay.
06:56.600 --> 07:02.000
But when you operate at the scale of Microsoft 365, you aren't just building new things. You have thousands of legacy APIs and older programs just kind of floating around.
07:02.100 --> 07:04.000
So they didn't all get the memo.
07:04.100 --> 07:08.500
Exactly. Just because you closed the coat check doesn't mean every old piece of software got the message.
07:08.600 --> 07:12.000
So the old software is still standing in line trying to hand over its ticket.
07:12.100 --> 07:13.500
And waiting.
07:13.600 --> 07:14.500
Yeah.
07:14.600 --> 07:22.000
And waiting. And if a legacy API is still hardwired to look for that old KV cache, and the cache obviously stops responding because of the deprecation update, the API triggers a timeout. It waits so long that eventually the end user just gets a completely blank screen.
07:22.100 --> 07:23.800
Wow.
07:23.900 --> 07:29.800
You can test a million scenarios in a sandbox, sure, but replicating the exact chaotic, legacy-entangled environment of the real, massive production world, it's nearly impossible.
07:29.900 --> 07:34.500
It's akin to trying to replace the engine of a commercial jet while it's cruising at 30,000 feet.
07:34.600 --> 07:38.200
Which perfectly explains why these seemingly minor adjustments cause such havoc.
07:38.300 --> 07:44.000
Yeah, like the reports noted that virtual desktop users lost their optimized Teams experience because of a—get this—seemingly minor routing change.
07:44.100 --> 07:45.200
Right.
07:45.300 --> 07:50.000
And globally, OneNote on iOS had sign-in problems traced back to a single line of routing code being tweaked in a specific software build.
07:50.100 --> 07:53.500
But notice the remediation strategy for almost every single one of these incidents in the reports.
07:53.600 --> 07:56.500
Yeah, it was always rollback. Just reverting to the previous state.
07:56.600 --> 08:01.500
Reverting to a previous known good state remains the single most effective survival strategy in cloud engineering.
08:01.600 --> 08:03.200
Because you can't fix it live.
08:03.300 --> 08:10.000
No. You do not try to hot-fix the complicated dynamic claims translator or the routing code while millions of users are actively locked out. You just roll the entire environment back to yesterday's configuration.
08:10.100 --> 08:14.500
Okay, so if human oversight can't always catch the butterfly effect, and the front end lies to us about where the problem is—
08:14.600 --> 08:16.000
Right.
08:16.100 --> 08:19.500
We kind of have to rely on our administrative dashboards to tell us the truth.
08:19.600 --> 08:21.800
Yeah, you would hope so.
08:21.900 --> 08:28.000
But during this late August window, multiple administrative data services experienced severe reporting delays. We aren't even talking about the apps breaking here; we are talking about the monitoring tools breaking.
08:28.100 --> 08:31.000
Ah, the telemetry mirage.
08:31.100 --> 08:33.800
Here's where it gets really interesting.
08:33.900 --> 08:38.000
This is perhaps the most insidious issue in the entire stack of reports, honestly.
08:38.100 --> 08:52.500
Yeah. The reports show that Microsoft 365 Copilot usage and adoption data was delayed for users across North America and Europe. Huge delay. And the Microsoft 365 admin center, Viva Insights—which by the way includes Copilot readiness data and the adoption score reports—they all lagged days behind reality. And on top of that, a standard .NET service update introduced a code regression that completely froze the Microsoft 365 Apps device inventory update status.
08:52.600 --> 08:58.000
So basically, the engine of the car is running perfectly fine, but the speedometer on the dashboard is jammed at zero.
08:58.100 --> 09:05.500
Exactly. Let's put ourselves in the shoes of the listener for a second. If you are an IT director and you just spent, you know, millions of dollars of your annual budget buying Copilot licenses—
09:05.600 --> 09:07.500
Oh, boy.
09:07.600 --> 09:13.800
You have staked your annual bonus on this rollout. You log into your dashboard on a Thursday morning, and you see Copilot usage absolutely flatlining.
09:13.900 --> 09:15.500
Zero growth.
09:15.600 --> 09:23.000
Zero growth, zero adoption for days. A frozen dashboard isn't just a technical glitch in that moment; it is a full-blown career panic attack.
09:23.100 --> 09:24.800
Completely.
09:24.900 --> 09:28.500
How do you know if the tool is actually dead or if it's just the dashboard playing tricks on you?
09:28.600 --> 09:34.000
If we connect this to the bigger picture, that panic really highlights a fundamental concept every modern professional needs to grasp.
09:34.100 --> 09:35.400
What's that?
09:35.500 --> 09:39.500
The distinction between service availability and data availability.
09:39.600 --> 09:42.000
Okay, break that down. How are they different?
09:42.100 --> 09:46.000
So, service availability means the tool itself is functioning.
09:46.100 --> 09:47.400
Right.
09:47.500 --> 09:54.000
Your employees can open Copilot, they can ask it to draft a complex project proposal, and it successfully generates that text. The actual workload is doing its job.
09:54.100 --> 09:56.000
The tool works.
09:56.100 --> 09:59.000
The tool works. But data availability means the telemetry pipeline is functioning.
09:59.100 --> 10:03.000
The telemetry pipeline being—
10:03.100 --> 10:05.500
The system that watches the user.
10:05.600 --> 10:13.200
Exactly. The hidden nervous system. It watches the user draft the email, records that action, processes the analytics in the background, and eventually updates your administrative dashboard.
10:13.300 --> 10:15.000
Oh, I see.
10:15.100 --> 10:17.500
And they run on entirely different infrastructures.
10:17.600 --> 10:18.800
Yeah.
10:18.900 --> 10:24.000
In this specific incident, Microsoft identified an upstream component involved in report data access that just—it just stopped responding.
10:24.100 --> 10:27.000
So the data was there, it just wasn't moving.
10:27.100 --> 10:32.000
Right. The usage data was queuing up in a massive traffic jam, but it wasn't making it to the administrative user interface.
10:32.100 --> 10:35.800
And the .NET update freezing the device inventory is another perfect example of that.
10:35.900 --> 10:41.000
Exactly. The laptops and endpoints out in the real world were still downloading their security updates. They were perfectly safe.
10:41.100 --> 10:43.500
But the admin center wasn't reflecting it.
10:43.600 --> 10:48.000
Right, because a code regression severed the reporting link between the devices and the dashboard.
10:48.100 --> 10:53.000
So the danger here isn't necessarily that the systems are down; the real danger is the human reaction to the stale data.
10:53.100 --> 10:57.000
Operating off a telemetry mirage leads to disastrous operational decisions.
10:57.100 --> 10:58.500
Like what?
10:58.600 --> 11:03.500
Well, if you see Copilot usage flatlining and you don't check the underlying service health reports to confirm a known telemetry delay—
11:03.600 --> 11:04.800
Mhm.
11:04.900 --> 11:08.500
You might pause a multi-million-dollar training initiative.
11:08.600 --> 11:10.200
Oh, wow.
11:10.300 --> 11:15.500
Yeah, or you might send out an angry company-wide email demanding people use a tool they are literally already using.
11:15.600 --> 11:18.000
Or worse, with the frozen device inventory.
11:18.100 --> 11:24.000
Exactly. Support teams might start running aggressive troubleshooting scripts or even remote wipes on endpoint devices because the admin center says they are horribly out of date.
11:24.100 --> 11:26.200
Oh, that's a nightmare.
11:26.300 --> 11:32.500
They end up breaking perfectly healthy machines to fix a problem that only exists on a frozen dashboard. You must always validate report freshness before making a high-stakes decision.
11:32.600 --> 11:38.500
That makes total sense. So what does this all mean? If humans can't keep up with this invisible complexity, and our dashboards can't always report it accurately, how on earth do we actually govern these systems?
11:38.600 --> 11:41.200
That's the big question.
11:41.300 --> 11:48.500
Because keeping these platforms compliant with international laws seems honestly mathematically impossible without an army of auditors. But Microsoft's answer to that is kind of tucked away in a major update from the Message Center reports.
11:48.600 --> 11:52.500
Yeah, the AI-powered regulatory templates for Purview Compliance Manager.
11:52.600 --> 11:59.000
Right. Tucked in the notes, Microsoft announces they are introducing a feature that uses artificial intelligence to take highly complex, dense regulatory PDF documents—
11:59.100 --> 12:02.500
The kind written in deep legalese by government bodies, yeah.
12:02.600 --> 12:07.800
Exactly. And it converts them directly into actionable IT controls and assessments within your network.
12:07.900 --> 12:11.000
Literally translating the law into network configuration.
12:11.100 --> 12:18.500
But the really interesting detail in the report is that the worldwide general availability for this feature was just pushed back. It was supposed to happen in August, but it's been delayed to early or mid-October 2026.
12:18.600 --> 12:24.500
Which is telling. Pushing a release date for a core compliance tool usually indicates they are making absolutely sure the underlying translation engine is bulletproof.
12:24.600 --> 12:27.200
Before unleashing it on enterprise governance data.
12:27.300 --> 12:28.800
Exactly.
12:28.900 --> 12:31.500
But I've got to ask: there is so much hype around AI right now.
12:31.600 --> 12:33.200
Oh, definitely.
12:33.300 --> 12:41.800
Every single tech company slaps "AI-powered" on their press releases. Is turning a PDF into an IT control actually a game changer, or is this just another shiny new button that looks great in a demo, but doesn't actually change how the IT department operates?
12:41.900 --> 12:48.000
This raises an important question, but honestly, this is a massive paradigm shift. It points to a complete structural change in how enterprise environments will operate over the next decade.
12:48.100 --> 12:51.500
Why is this so structurally different from what we do right now?
12:51.600 --> 12:56.500
Consider how compliance has historically worked, right? A regulatory body in Europe passes a new data privacy standard.
12:56.600 --> 12:59.000
Right, GDPR or something.
12:59.100 --> 13:04.000
Exactly. An organization's legal team sits down and reads a 300-page PDF. Then they schedule a dozen meetings with the IT security architects.
13:04.100 --> 13:06.500
Sounds exhausting already.
13:06.600 --> 13:14.500
It is. Those humans manually translate the legal jargon into technical requirements. The lawyers say, "Section 4 requires strict data compartmentalization," and the IT team translates that into, "Okay, we need to enforce 90-day password rotations and encrypt this specific data silo."
13:14.600 --> 13:17.000
So it's incredibly slow.
13:17.100 --> 13:21.000
Slow, highly manual, and extremely prone to misinterpretation.
13:21.100 --> 13:25.500
It's like a corporate game of telephone where the message gets distorted at every single step.
13:25.600 --> 13:30.000
Exactly. But what this Purview update represents is a move away from that human-bottlenecked translation. The AI ingests the regulatory source material and directly maps it to operational controls.
13:30.100 --> 13:32.000
Wow.
13:32.100 --> 13:39.000
It is like having a legal translator that instantly rewrites the company rulebook, pushing the actual technical configurations directly into the system every time a judge bangs a gavel.
13:39.100 --> 13:42.500
It really shows us that AI is moving past being just a generative novelty.
13:42.600 --> 13:47.000
Yeah, it isn't just a chatbot you ask to write a polite email to your boss or summarize a long meeting anymore.
13:47.100 --> 13:50.500
No, it is becoming a structural architect for corporate governance.
13:50.600 --> 13:57.500
And the environment demands it. As we explored with those broken adaptive cards and the legacy KV caches, the cloud environment is just too interconnected, too complex, and changes far too rapidly for manual human oversight to catch everything.
13:57.600 --> 14:02.000
So if the infrastructure is dynamic and invisible, the compliance mechanisms have to be equally dynamic and AI-driven.
14:02.100 --> 14:03.500
Exactly.
14:03.600 --> 14:10.000
Synthesizing everything we've pulled from this late August snapshot of the cloud, I think a very clear picture emerges for anyone navigating this space. The overarching theme is just invisible complexity.
14:10.100 --> 14:13.200
Yeah, cloud infrastructure is a deeply interconnected web.
14:13.300 --> 14:19.500
When you are trying to figure out why a shared link in Teams is broken, or why an automated workflow just vanished into thin air, you have to look past the immediate symptom.
14:19.600 --> 14:23.000
The error message staring at you on your screen is rarely the root cause.
14:23.100 --> 14:28.500
Right. And routine updates carry a massive butterfly effect. Tightening a simple authorization rule can accidentally lock out thousands of legitimate users.
14:28.600 --> 14:32.800
Or retiring an old, forgotten cache can take down an entire Bookings page.
14:32.900 --> 14:38.200
And crucially, we have to remember that our diagnostic dashboards can sometimes freeze while the engine is still running smoothly under the hood.
14:38.300 --> 14:41.500
Trust your telemetry, but always, always verify its freshness.
14:41.600 --> 14:47.500
Absolutely. Because whether you are troubleshooting a massive corporate network or just trying to navigate the digital tools for your own small business, you have to think about the layers beneath the surface.
14:47.600 --> 14:50.000
You can't just look at the light switch on the wall.
14:50.100 --> 14:55.000
No, you have to visualize the wiring hidden in the walls, the power lines down the street, and the entire grid feeding the city.
14:55.100 --> 14:58.200
The modern professional really has to become a systems thinker.
14:58.300 --> 15:04.000
Which leads me to one final thought I want you, our listener, to mull over as we wrap up today. It builds on everything we've explored.
15:04.100 --> 15:06.000
Okay, let's hear it.
15:06.100 --> 15:23.000
We know that hidden dependencies cause unpredictable, cascading failures. We know that routine, well-intentioned changes can break systems in really bizarre ways. And we know that administrative dashboards can utterly fail to report reality. Now, we are entering an era where our complex compliance rules are going to be written and deployed by AI, and our daily workflows are going to be managed by AI Copilots. So, what happens in a few years when an AI-generated configuration change breaks a hidden dependency that an AI-generated dashboard completely fails to notice?
15:23.100 --> 15:26.500
Wow. The ultimate blind spot.
15:26.600 --> 15:36.500
Right. Who fixes the machine when the machine doesn't even know it is broken? It makes that simple light switch look pretty good in comparison. Keep thinking on that, and keep looking beneath the surface. We'll catch you on the next deep dive.
15:36.600 --> 15:47.500
You've been listening to Support Engineering Weekly from the Support Engineering Blog. For the full articles, references, and technical resources from today's discussion, visit the URL blog.sadhan.ch.