Updated: 1 hour ago
Lab 13 — Azure Monitor, KQL, Alerts, and Network Diagnostics
azure administrator series
Lab 13 neon cover illustration. AI-generated artwork, not Azure validation evidence.
ZIP SHA-256: b434e49489b3cfa17b5d9f7c70abe83946cc86487394f4e89486becd040bec02. A fresh public download was extracted and its individual file hashes verified before publication.
The VM is running. Its data is intact. Its network path works. Yet newly generated messages are missing from Log Analytics. In this workshop, distinguish machine health from telemetry health, investigate the collection path, and recover only the failed relationship.
Allow 180–240 minutes, plus bounded Azure propagation waits. Use Azure CLI, PowerShell 7, Bicep, Python, KQL, and Portal. This independent training exercise addresses the AZ-104 monitoring objectives: metrics, log settings and queries, alert rules/action groups/processing rules, Insights, Network Watcher, and Connection Monitor. It is not an official Microsoft exam lab and does not cover every certification objective.
1. Understand the design
One isolated West Europe resource group contains a small Ubuntu VM, outbound-only public IP, deny-all inbound NSG, subnet-restricted storage, a Log Analytics workspace, two DCRs, agents, diagnostics, and alert rules. The VM's managed identity reads/writes only the lab blob container. No workstation IP allow rule is required because source traffic originates inside Azure.
Two collection paths deliberately remain independent:
Classic VM Insights performance profile: \VmInsights\DetailedMetrics, 60-second sampling, Microsoft-InsightsMetrics.
Syslog: local0, informational severity and above, destination Syslog.
The documented classic logs-based profile is used unchanged for KQL teaching. Microsoft now recommends the newer OpenTelemetry experience for new monitoring deployments. This lab does not silently onboard an Azure Monitor workspace or deploy those additional resources. Compare the experiences in Microsoft's VM monitoring guidance.
Storage uses a service endpoint and selected-network firewall, not a private endpoint. A successful TCP connection does not establish blob authorization; OAuth transfer and hash checks do.
2. Prepare and review
Use installed PowerShell 7.5+, Azure CLI/Bicep, and compatible Az.Accounts, Az.Resources, Az.Monitor, Az.Network, and Az.OperationalInsights. Authenticate CLI and PowerShell to the same tenant, subscription, and operator beforehand. The scripts never perform sign-in or consent automatically.
Keep the state outside the extracted public package:
$state = 'C:\LabPrivate\Lab13\state.json'
./Start-Lab13.ps1 -StatePath $state -Stage Preflight
./Start-Lab13.ps1 -StatePath $state -Stage Preflight -ExecuteIf governance assignments exist, inspect the privately captured policy/lock/deny inventory before repeating preflight with -ReviewedGovernance. Do not remove policies or add exemptions. Preflight also verifies permissions, providers, quota, required image/SKU, address conflicts, current pricing, existing Network Watcher, and official agent releases. No tool upgrades, quota requests, or provider registrations are automatic.
The address space is 10.113.0.0/24; workload subnet 10.113.0.0/26. The public IP supports outbound connections only. NSG priority 100 denies all inbound traffic, including SSH; administration uses Run Command.
3. Deploy the foundation
Read templates/foundation.bicep: parameters carry the run identifier and tags; symbolic resources define dependencies; the container-scoped role references the VM identity. Outputs are private identifiers, not published evidence.
./Start-Lab13.ps1 -StatePath $state -Stage Foundation -Execute
# Inspect the private ARM build, validation, and incremental what-if.
./Start-Lab13.ps1 -StatePath $state -Stage Foundation -Execute -ReviewedWhatIfThe first invocation creates only the owned empty group and private disposable SSH material, validates the template, and stops for review. It does not submit the chargeable deployment without -ReviewedWhatIf. Review every proposed Create/Modify; no unrelated IDs or deletes are acceptable. The completed template cannot be replayed accidentally.
Portal checkpoints: resource group inventory; VM Ubuntu/B2s/32 GiB disk/identity; subnet default outbound disabled; inbound deny rule; storage HTTPS/TLS/Shared Key settings and subnet-only firewall; exact container role.
Genuine Azure Portal: isolated baseline resource inventory. Identifiers are masked.
4. Establish telemetry and data
./Start-Lab13.ps1 -StatePath $state -Stage Telemetry -Execute
# Review the telemetry-only incremental what-if.
./Start-Lab13.ps1 -StatePath $state -Stage Telemetry -Execute -ReviewedWhatIf
./Test-Lab13.ps1 -StatePath $state -Phase Baseline -ExecuteOfficial Azure Monitor Agent and Network Watcher Agent are installed. Separate DCR associations attach the unchanged performance profile and narrow Syslog stream. Blob reads/writes use resource-specific StorageBlobLogs, not AzureDiagnostics.
The guest checkpoint verifies exact VM identity through IMDS, creates a tiny synthetic file, obtains a managed-identity token in memory, uploads/downloads the blob, compares SHA-256, emits a unique local0.info marker, and confirms the marker exists locally. No key or token is printed.
An exact Connection Monitor child is created under the existing regional Network Watcher. Its VM-to-blob TCP 443 check uses IPv4 preference, one-minute frequency, no traceroute, and the lab workspace. The workspace-local NetworkMonitoring solution is included; the retired Log Analytics agent is not installed.
Verify fresh Heartbeat, InsightsMetrics, Syslog, and StorageBlobLogs records, platform metrics, actual VM/Storage Insights views, effective NSG rules, and an external blocked-SSH probe. Table presence alone is insufficient: filter the exact run and UTC window. Wait at most 30 minutes per gate; a timeout does not pass.
Actual downloadable Bicep source: independent collection paths. Coding view, not an execution result.
Genuine Portal: official AMA and Network Watcher Agent versions and successful provisioning.
Genuine Portal: the recorded local0 source has LOG_INFO as its minimum level; other facilities remain None.
Genuine Portal: Storage Read and Storage Write are enabled, Storage Delete and metric export are disabled, and only the recorded Log Analytics destination is selected.
5. Query with KQL
Open workspace Logs, choose the lab scope, and use the private exact VM ID from your manifest. Start with the examples in queries/lab13.kql. Replace placeholders locally; never publish filled-in identifiers.
Syslog
| where TimeGenerated > ago(15m)
| where _ResourceId =~ '<exact lab VM ID>'
| where Facility == 'local0'
| project TimeGenerated, ingestion_time(), SeverityLevel, SyslogMessage
| order by TimeGenerated descTeach filtering (where), columns (project), aggregation (summarize), time bins (bin), and correlation (join). TimeGenerated reflects event time; ingestion_time() helps distinguish delayed arrival from a missing source. Use unique nonces for baseline, fault, and recovery. Old records cannot prove present-day recovery. A join of independent streams is an investigation aid, not proof of causation.
Portal captures: both DCRs and VM associations, narrow Syslog source, workspace retention/cap, Logs results, VM Insights, Storage Insights, and Blob diagnostic categories. Azure exposes the configured quota as 1 GB/day in Portal (dailyQuotaGb=1). This daily cap is secondary protection; collection limits and bounded source traffic are the primary cost controls. Daily-cap limitations.
Genuine Portal: current pay-as-you-go tier and a 1 GB/day daily-cap setting. The displayed estimate is not a billed-cost assertion.
Genuine Portal: the configured workspace retention is 31 days.
Genuine Portal/KQL: fresh independent telemetry streams in the isolated workspace.
Genuine classic VM Insights: actual CPU, memory, and disk measurements.
Genuine Storage Insights: measured transactions, availability, and latency.
6. Exercise alerts without sending messages
./Start-Lab13.ps1 -StatePath $state -Stage Alerts -Execute
# Review the alert-only what-if.
./Start-Lab13.ps1 -StatePath $state -Stage Alerts -Execute -ReviewedWhatIfThe enabled action group has no receivers. The CPU rule is stateful: five-minute average over 20%, evaluated every minute. Two self-terminating guest processes generate at most five minutes of load. The log rule is stateful: the exact VM/run's reserved synthetic marker yields more than zero rows in five minutes, evaluated every minute. Emit that marker once.
Observe actual alert-instance Fired and Resolved monitor conditions. Do not confuse the user-managed New/Acknowledged/Closed alert state with its monitor condition. Resolution can lag behind the source becoming healthy.
Inspect the one-hour maintenance processing rule: only the owned group and exact two alert IDs, RemoveAllActionGroups. Processing rules alter actions, not whether an alert exists. With empty receivers, configuration is testable, but external delivery and notification suppression are not tested. Do not add fake emails or use a test-notification button. Processing-rule behavior.
Capture the rules, receiver-free action group, processing filter/schedule, and both observed transitions. If an alert does not transition within its 30-minute bound, stop that release gate rather than lowering a threshold to manufacture a pass.
Genuine Portal: empty notification and action lists; no test message was sent.
Genuine Portal: one-hour processing rule, owned-group scope, and a two-rule filter. External notification suppression was not tested.
Genuine Portal: CPU alert observed Fired.
Genuine Portal: synthetic Syslog alert observed Fired.
Genuine Portal: the CPU alert observed Resolved.
Genuine Portal: the same Syslog alert observed Resolved.
7. Introduce the missing-telemetry fault
Save a healthy configuration snapshot first. Then:
./Invoke-Lab13Fault.ps1 -StatePath $state -Execute
./Test-Lab13.ps1 -StatePath $state -Phase Fault -ExecuteCLI removes only the recorded Syslog association, not the DCR, performance association, agent, or workspace. Allow configuration propagation before a ten-minute source observation. Generate unique fault-phase messages and confirm them locally. Query the exact measured window and nonce; account for cached configuration and late ingestion. Deleting an association alone does not prove collection stopped.
If the complete initial window contains cached or late-arriving markers, its gap check fails. Retain that observation. The package permits one explicit additional ten-minute source window, with a new nonce and another five-minute late-ingestion wait, using ./Test-Lab13.ps1 -StatePath $state -Phase Fault -Execute -NewFaultWindow. It archives the first results and does not change any Azure configuration. A second nonzero result stops the release gate; do not retry indefinitely or remove inconvenient rows. The live workshop encountered this propagation behavior; the validation report records the subsequent measured result.
The failure is a telemetry gap—not a VM, application, or storage outage. Fresh performance/heartbeat, healthy Connection Monitor samples, successful OAuth reads, unchanged file hash, identity, NSG, DCR contents, and agent configuration prove that distinction. Retain the actual query response and timestamps privately.
Use CHALLENGE.md before reading the hints or solution.
Actual CLI fault code: deletes only the recorded Syslog association. Coding view, not terminal output.
Genuine Portal: no VM remains associated with the lab Syslog DCR. This configuration view alone does not prove a collection gap.
Genuine Portal/KQL: six initial-window messages arrived after association removal, consistent with configuration propagation. This interim result was not counted as a passing gap.
Genuine Portal/KQL: no new fault-window markers at the final measured checkpoint; independent streams remain fresh.
8. Recover only the relationship
./Restore-Lab13.ps1 -StatePath $state -Execute
./Test-Lab13.ps1 -StatePath $state -Phase Recovery -Execute
./Restore-Lab13.ps1 -StatePath $state -ExecutePowerShell recreates the captured association name on the exact VM URI, pointing to the recorded Syslog DCR. A bounded ten-minute stream of new recovery markers spans agent configuration propagation; at least one of those new events must arrive. Code checks original hashes and unchanged configuration. A second recovery verifies the existing exact association and performs no configuration mutation. Its single fresh validation marker is new test traffic, not a duplicate association.
Restoring the association re-enables collection; it does not prove backfill of previously uncollected messages. Transition markers may be missed while the agent refreshes configuration. Record actual new-event counts, then use separate post-recovery markers to prove ongoing collection.
Do not restart/reinstall AMA, edit DCR contents, weaken networking, or change workspace destinations to force recovery. If the manifest has a pending operation, use Reconcile-Lab13.ps1; it inspects the exact operation, never blindly replays it.
Actual PowerShell recovery source: restores only the recorded association.
Genuine Portal: the recorded VM is associated with the original Syslog DCR again. Fresh-event ingestion is verified separately below.
Genuine Portal/KQL: newly generated recovery markers arrive.
9. Practise network diagnostics separately
./Start-Lab13.ps1 -StatePath $state -Stage NetworkDiagnostics -Execute
# Add -PauseForEvidence to stop at each measured state for genuine Portal captures.First prove TCP 81 fails from the VM. Change only the monitor test port from 443 to 81 with CLI, observe ChecksFailedPercent, then restore 443 with PowerShell and observe successful checks and round-trip measurements. This is a misconfigured monitoring test, not a storage outage.
Inspect IP flow verification for inbound SSH denial, next hop, and connection troubleshooting for blob TCP 443. TCP reachability tests packet delivery; it does not authenticate storage. Neither flow logs nor packet captures are enabled. The shared watcher remains unchanged; only the exact recorded monitor child belongs to this lab.
Genuine Portal: baseline checks failed 0%, with actual round-trip measurements.
Genuine Portal: the separate incorrect-port monitor test reports measured failure.
Genuine Portal: restored TCP 443 monitoring reports measured success.
10. Clean up and verify
./Remove-Lab13.ps1 -StatePath $state -Execute
./Remove-Lab13.ps1 -StatePath $state -Execute
./Export-Lab13Evidence.ps1 -StatePath $state
./Test-Lab13Safety.ps1
./Test-Lab13Static.ps1
./Test-Lab13Package.ps1Cleanup disables/removes the lab alert rules and processing rule, disables the monitor's single recorded V2 test group before deleting that exact child, deletes the recorded container role and diagnostic/collection relationships, and removes only the owned group. The returned disabled configuration must match the captured monitor with only that flag changed. Unexpected resources, associations, locks, or ownership changes block deletion. A second absence check is required. Confirm the shared Network Watcher is unchanged.
Log Analytics uses normal soft deletion: data/configuration remain recoverable for 14 days, not permanently purged. This retained state is separate from active-resource absence. Private audit manifests remain local; temporary SSH material is removed. Workspace deletion.
Genuine Portal: the owned lab resource group no longer exists after cleanup.
Evidence and further practice
Review the validation report, sanitized evidence, package hashes, and knowledge checks. Genuine Portal/coding/KQL captures document actual states. Illustrations explain the design but never stand in for a successful test. No actual-phone testing or notification-delivery claim is made.
Previous: Lab 12 — Azure App Service Operations.
More: Azure Workshopz.
Challenge — The healthy VM with missing messages
The operator confirms the VM is running and fresh heartbeat/performance data continues to arrive. A synthetic blob can still be read using the VM's identity, and its hash has not changed. Network monitoring also reports healthy TCP reachability.
However, new synthetic local0 messages generated during the observation window do not appear in the expected Log Analytics results. Earlier messages remain searchable.
Find the discrepancy, identify evidence that rules out unrelated failures, make the smallest authorized recovery, and prove success using new events. Preserve identity permissions, DCR contents, agent configuration, network restrictions, and data. Do not rebuild anything.
Deliver: local source evidence; exact UTC/query window; independent health signals; root cause; targeted recovery; fresh arrival; unchanged hash/configuration; no-op repeat; cleanup confirmation.
Progressive hints
Separate event generation, collection configuration, transport, destination, and your query. Which evidence proves each stage?
Old searchable events establish historical ingestion, not current collection. Use a new unique marker and inspect event and ingestion timestamps.
A workspace can receive one stream while another fails. Compare the VM's relationships for the performance and Syslog paths.
The rule's contents and existence do not prove that the VM is associated with it. Compare exact associations to the private baseline.
Restore only the missing recorded relationship. Then generate a new marker; never use an old baseline result as recovery proof.
Separate solution
Reveal the solution after attempting the challenge
The controlled fault deletes the recorded l13-syslog DCR association from the owned VM. The Syslog rule, destination workspace, official agent, performance association, identity, data, and networking remain unchanged.
First prove the symptom after propagation: fresh local0 messages exist locally during the ten-minute window but their unique nonce is absent from the measured workspace query. Allow five further minutes for late ingestion, then perform a separate fresh OAuth/hash health checkpoint. Fresh Heartbeat/InsightsMetrics and successful storage/hash/network checks rule out a claimed machine or data-path outage. If cached collection delivers the initial markers, that gap gate has not passed. Retain it; one explicit -NewFaultWindow observation is permitted after the full first window, without changing Azure configuration. If that additional window also contains markers, restore the relationship and stop publication rather than claiming a gap.
Restore-Lab13.ps1 -StatePath <private state> -Execute uses PowerShell to recreate the captured association name on the exact recorded VM URI and DCR ID. It does not reinstall or restart the agent, edit the DCR, or change networking.
Generate new recovery events, observe their arrival, verify original hashes and unchanged controls, run Recovery validation, then invoke recovery again. The existing correct association must cause no configuration change. Validation traffic remains explicit.
The separate Connection Monitor exercise intentionally changes only its TCP test port to the previously proven closed port 81. Restore 443 and verify new measured samples. That exercise changes monitoring configuration, not storage availability.
Complete both cleanup absence checks. Preserve the shared Network Watcher and report normal workspace soft-deletion retention separately.
Eight knowledge checks
Does a running VM prove fresh Syslog collection? No. Source, association, rule, agent, transport, destination, and query need separate evidence.
What is the difference between a DCR and a DCR association? The rule defines collection/routing; the association connects the resource to it.
Can historical events prove recovery? No. Generate unique recovery markers and verify their new arrival.
How do event and ingestion times differ? Event time describes the source event; ingestion time describes arrival into the query service. Delays can mimic a gap if windows are chosen poorly.
Do alert processing rules prevent alert creation? No. They modify alert actions, such as removing action groups during maintenance.
What can an action group with no receivers prove? Its configuration and alert associations. It cannot prove external delivery or notification suppression.
Does successful TCP 443 prove Blob OAuth access? No. TCP tests connectivity; identity authorization and data-integrity checks are additional tests.
Does a Log Analytics daily cap guarantee the spending ceiling or immediately erase deleted data? Neither. Bound collection/traffic/costs separately; normal workspace deletion retains recoverable data/configuration for 14 days.
Validation report — Lab 13
Core release status: passed, measured on 11 October 2026. All timestamps below are UTC. This report describes an actual disposable Azure run, not inferred results from deployment status.
Measured exercise results
Fresh Heartbeat, InsightsMetrics, Syslog, StorageBlobLogs, VM platform metrics, and the classic VM/Storage Insights views were verified. OAuth upload/download preserved the synthetic dataset SHA-256: 966c507c3393c03b7a8a249403d33741f0d26e5e699bf55867267826421cdeab. Effective NSG inspection and an external TCP probe confirmed public SSH was blocked.
The recorded Syslog association was removed; the DCR and independent performance association remained unchanged. The initial complete window produced 6 ingested messages during configuration propagation; it was retained and was not counted as a passing gap. Initial-window event timestamps ran from 2026-10-11T19:48:25.893087Z through 2026-10-11T19:50:55.90898Z; the last ingestion timestamp was 2026-10-11T19:51:14.0799252Z. This was retained as propagation evidence, not erased. One explicit additional window used a new nonce without changing Azure configuration. The guest emitted 20 local messages from 2026-10-11T20:07:07Z to 2026-10-11T20:17:07Z. At 2026-10-11T20:22:38.8926207+00:00, that new fault-window marker count in the workspace was 0, after an additional 5-minute late-ingestion observation. Fresh Heartbeat and InsightsMetrics counts were 10 and 351. A new guest checkpoint also verified OAuth access and the original hash. This demonstrates missing collection, not an application or VM outage.
PowerShell restored the exact recorded association. The guest generated 20 new transition markers from 2026-10-11T20:24:34Z to 2026-10-11T20:34:34Z. The first successful recovery query observed 5 of those new records at 2026-10-11T20:35:03.5776604+00:00. This proves fresh collection, not delivery of every transition marker or backfill of previously missed messages. Separate Recovery validation and repeated recovery used additional new markers. Original content/hash and configuration were retained; repeated recovery made no configuration change. It still generated fresh validation traffic.
MetricAlert: Fired at 2026-10-11T19:24:48.9414045Z; Resolved at 2026-10-11T19:34:53.5662036Z. The same recorded alert instance was checked.
LogAlert: Fired at 2026-10-11T19:26:42.1744979Z; Resolved at 2026-10-11T19:41:35.9697069Z. The same recorded alert instance was checked.
The separate Connection Monitor port exercise produced at least two measured failed-check samples on TCP 81, then at least two successful samples and measured round-trip data after TCP 443 was restored. IP flow verification denied inbound SSH; next-hop and connection-troubleshooting responses were inspected. TCP reachability was not treated as proof of OAuth authorization.
The initial monitor metrics request was rejected because its window was shorter than one minute. The polling helper was corrected to wait for the minimum window. The exercise resumed from the exact recorded port change without replaying that mutation; only subsequent measured samples satisfied the gates.
The installed CLI also rejected the initial IP-flow diagnostic without an explicit resource-group argument. The diagnostic helpers were corrected to supply the exact recorded group. Only the independent diagnostics were rerun; the successful monitor fault/recovery was not replayed.
Cleanup and repeated cleanup found no active recorded lab objects or role assignment. The shared West Europe Network Watcher was unchanged. Temporary SSH files were removed. The Log Analytics workspace used normal soft deletion, retaining its normal 14-day recovery window; no permanent purge was requested.
After Azure deletion completed, cleanup initially stopped on OpenSSH's explicit broad grants on its public-key file. The private key had already been removed; private state remained restricted. The public-key grants were narrowed, the creation helper was corrected to check both generated files, and the exact interrupted cleanup was reconciled without recreating resources. Final absence and temporary-material checks then passed.
Static checks and safety simulations
All three Bicep templates built. Azure template validation and reviewed incremental what-if passed before the three deployments. The foundation build's fixed disposable administrator-name linter warning was reviewed; SSH is denied and no password login is configured. An available-tool-update notice did not cause an upgrade.
PowerShell syntax/interface checks and PSScriptAnalyzer 1.25.0 passed with no unresolved warning/error findings. Four recorded conventions were reviewed separately: approved helper verbs, singular helper nouns, ShouldProcess versus this series' explicit Execute contract, and analyzer closure-related unused-parameter findings. These are not represented as a completely unfiltered analyzer pass.
All 13 offline guard/interface and local credential-file checks passed: wrong context, mismatched VM/DCR/workspace, exclusive-lock concurrency, pending-operation rejection, interrupted-cleanup no-premature-pass, and preview entry points. Guard faults were simulated/offline, not live intentional wrong-tenant mutations. The key-file ACL check used the installed official key generator locally, with no Azure calls.
Scope and publication controls
Action-group receiver arrays were empty. Alert processing-rule scope, rule filter, schedule, and removal action were verified. External notification delivery and notification suppression were not tested. OpenTelemetry onboarding, flow logs, and packet capture were not performed. No actual-phone testing is claimed.
Portal screenshots are genuine; only identifiers are opaquely masked. The coding pictures display the actual package source, not terminal execution output. The neon cover is an AI-generated illustration and is never validation evidence.
The source package is allowlisted and credential-scanned. ZIP extraction and per-file SHA-256 checks are performed after this report is saved. Fresh public-download verification is a separate publication gate: the article records the final ZIP hash only after that public download passes. The ZIP cannot contain its own final hash or a receipt generated after its upload.
The refreshed six-hour estimate was EUR 6.93, below EUR15 active allowance, retaining EUR5 cleanup reserve. An estimate is not a billed-cost assertion; the daily cap is not a guaranteed spending limit.
Core gate receipt
AlertConfiguration — passed at 2026-10-11T19:19:19.1086643+00:00.
Alerts — passed at 2026-10-11T19:42:21.7851131+00:00.
Cleanup — passed at 2026-10-11T21:13:43.0657654+00:00.
CleanupRepeat — passed at 2026-10-11T21:13:53.4270595+00:00.
Deployment-foundation — passed at 2026-10-11T18:52:35.3080247+00:00.
Deployment-telemetry — passed at 2026-10-11T19:01:19.1073049+00:00.
FaultAssociationRemoved — passed at 2026-10-11T19:42:59.6323952+00:00.
LogAlert-Fired — passed at 2026-10-11T19:27:37.8149393+00:00.
LogAlert-Resolved — passed at 2026-10-11T19:42:21.7743705+00:00.
MetricAlert-Fired — passed at 2026-10-11T19:25:29.7829399+00:00.
MetricAlert-Resolved — passed at 2026-10-11T19:35:31.1261995+00:00.
MonitorBaseline — passed at 2026-10-11T19:05:29.4507394+00:00.
MonitorFault — passed at 2026-10-11T20:51:18.8185685+00:00.
MonitorRecovery — passed at 2026-10-11T21:01:05.9123803+00:00.
MonitorStopped — passed at 2026-10-11T21:07:27.1403979+00:00.
NetworkDiagnostics — passed at 2026-10-11T21:06:08.5764171+00:00.
Preflight — passed at 2026-10-11T18:44:49.4651950+00:00.
Recovery — passed at 2026-10-11T20:35:06.1358637+00:00.
RecoveryNoOp — passed at 2026-10-11T20:46:40.3372768+00:00.
Telemetry — passed at 2026-10-11T19:10:25.6809750+00:00.
Validation-Baseline — passed at 2026-10-11T19:15:06.8595435+00:00.
Validation-Fault — passed at 2026-10-11T20:23:33.0203485+00:00.
Validation-Recovery — passed at 2026-10-11T20:43:44.5290683+00:00.
Comments