A gateway timeout changed from 20 seconds to 60 seconds. The booking service is under latency review. The two facts belong in the same investigation, but they do not yet belong in a sentence that says “caused by.”
For an operator, the immediate decision is practical: which change deserves attention, what does the available evidence actually establish, and what should another reviewer be able to recover tomorrow?
Azure provides rich evidence through Azure Monitor, the Activity Log, Azure Resource Graph, and related services. At workload scale, the challenge is correlating that evidence across resources, identities, and time while preserving the boundary between an observation and an interpretation. Azure Support Agent complements those platform capabilities with three connected, but distinct, tools: Change Explorer, Evidence Locker, and Case Files.
This article follows a fictional Contoso Booking review from a suspected configuration change to a reviewable investigation record. It is not a root-cause reveal. The useful outcome is a narrower question, preserved evidence, and an explicit next decision.
About the visual examples: Contoso Booking, its identities, and its investigation records are synthetic. These five animations were captured in the native interface using isolated browser-only fixtures, with no backend, Azure, or AI calls. Snapshot content was authored in the browser and hashes computed locally; the displayed verified badge is fixture state, not a backend verification result. These captures do not demonstrate persisted records or live incident validation.
The faster-paced, approximately 60-second tour visits all 13 Change Explorer tabs, then Evidence Locker content and a Case Files record. Its pacing is editorial, not a measure of investigation speed.
Begin with a hypothesis, not a verdict
Imagine the Booking team reviewing a release window after a report of slower requests. A gateway configuration event is nearby. Someone reasonably asks whether the timeout increase is involved. Someone else points out that it may have been a response to an existing symptom.
Both explanations deserve examination. A longer timeout changes how long a request may wait before timing out; the configuration value alone does not measure how long requests actually took. It does not identify the slow component, establish when the symptom began, or tell you why the setting was changed.
Start with a sentence that preserves those distinctions: “The gateway request timeout increased during the review window. Its relationship to the reported latency remains unverified.” That is a strong opening because it can survive new evidence. It identifies a concrete observation without making the entire investigation depend on the first plausible story.
The three features give that investigation different homes. Change Explorer saves a bounded analysis of change activity, including available attribution, property differences, and investigator annotations. Evidence Locker preserves a point-in-time bundle of selected content. Case Files maintains the ongoing record of questions, decisions, references, and follow-up.
Those records are not interchangeable. A Change Explorer run is not automatically an Evidence Locker snapshot. Its embedded case file is not a separate Case Files record. A note can explain a decision without preserving the underlying source payload. A snapshot can preserve content without explaining why an investigator considered it relevant.
For Contoso Booking, the working question becomes more precise: which gateway setting changed, what operation and identity are associated with it, what evidence was visible in the selected window, and what additional observation would distinguish cause from coincidence?
That question also defines a stopping point. The review should not expand into an indiscriminate export of the estate merely because more tabs are available. Gather what helps assess the hypothesis, record what is missing, and retain enough context for a second operator to challenge the reasoning.
Give the window a source and a boundary
In Change Explorer, begin with the workload or subscription, its connection, and an explicit start and end. Workload analysis uses the workload's bound connection; subscription analysis uses the selected or default connection. Confirm that the connection can read the intended evidence rather than assuming that a familiar workload name establishes access.
The analyzed window is especially important when reopening a saved run. Moving the selectors does not recollect it. If the interface warns that the saved window differs from the current selection, either load the intended historical analysis or analyze the intended window again. Do not silently give an older result a newer meaning.
Use absolute timestamps when comparing the release record, source events, and application telemetry. The time picker supports local and UTC entry, but browser-local preset boundaries and UTC-parsed conversational dates can differ. Recording the time zone makes “before the release” a reproducible statement rather than a shared assumption.
Scope also needs more explanation than its label. Workload + dependencies broadens explicit resources to their containing resource groups; it does not traverse a measured dependency graph. Tenant-wide broadens Resource Graph selection to already-resolved subscriptions, not necessarily every subscription visible to the connection.
The sources can cover different sets. Activity Log collection applies its own explicit-resource filtering when applicable, while optional Entra audit events are directory-wide. Workload exclusions are not a universal filter across every feed. A directory event appearing beside the gateway change therefore needs its own relevance check.
Read source diagnostics alongside the result. Required Resource Graph or Activity Log failures can make a run partial; optional identity failures and some collection caps may not. Activity Log collection covers only the first 25 resolved subscriptions and Succeeded or Accepted operations, so failed attempts are outside that result. The combined run retains at most 5,000 events before its final chronological sort, not necessarily the newest 5,000 across all sources.
Resource Graph's change collection joins current resources, which can leave deleted resources absent. Both change evidence sources are eventually consistent. A short result may justify a narrower repeat after source availability catches up, not a declaration that nothing happened.
For Booking, preserve the actual subscriptions, resource identifiers, window, source outcomes, and limitations. The standard is not “the analysis finished.” It is “the reader can tell which evidence this analysis could, and could not, have seen.”
Ask what the event actually attributes
Summary and Risk Insights can guide attention toward the gateway event. Operations can group related activity, while the timeline helps place it beside neighboring changes. These are useful navigation aids: they make a busy release window approachable without requiring every row to carry equal investigative weight.
An operation group is not necessarily a single authoritative transaction. Where a correlation identifier exists, it can support a relationship between events. Otherwise, grouping may use an actor and a nearby time burst. That is a reasonable investigative lead, but it needs to remain distinguishable from source-confirmed correlation.
Before opening the event drawer, review the AI boundary. Perform AI analysis starts unchecked in the UI, yet opening a change in a nonempty, non-demo run that has not been AI-analyzed also starts enrichment. Leaving the checkbox off is therefore not a guarantee of no later provider call. Where provider use is not approved, avoid that interaction; deterministic Technical Diff and saved-run exports do not use this drawer trigger.
The synthetic event drawer shows the gateway request timeout changing from 20 to 60 seconds alongside operation and actor context. In an authorized investigation, review the drawer's automatic AI behavior before opening an unanalyzed event.
For the Booking event, compare the operation, resource identifier, source timestamp, and actor information with the approved release record. Does the identity represent the expected deployment principal? Is the event for the gateway setting under review, or merely another operation in the same resource group?
Actor resolution is best-effort. Without the appropriate Microsoft Graph access, an identifier may remain unresolved. That does not mean the activity was anonymous. Conversely, a friendly display name does not establish which human approved a pipeline execution or why it ran. Preserve the underlying identifier and the distinction between source attribution and organizational accountability.
Risk and security labels help prioritize this work. They are derived assessments, not proof of malicious intent. Off-hours activity might be a planned release; an unfamiliar principal might be newly introduced automation. Optional AI text can sharpen a narrative, but can also be wrong, and enrichment does not necessarily cover every event. The investigator should cite the event and supporting context, not merely repeat its label.
Let the technical diff narrow the question
The technical difference is the center of the Booking story: the available before-and-after evidence shows the gateway request timeout moving from 20 to 60 seconds. That is much more useful than “the gateway was updated.” It identifies a specific configuration decision that the service owner can explain and test.
Move through Technical Diff, Actors, and Operations to inspect the setting, attribution, and grouped activity. The fictional 20-to-60-second timeout difference is configuration evidence, not a latency measurement, rollback, or proven cause.
Read the surrounding properties too. A gateway can have several settings, and a resource-level update may contain multiple differences. Confirm which setting serves the affected request path before treating the value as operationally relevant. The investigator's next question is about applicability, not whether the number looks surprising.
Keep the distinction between missing and unchanged. Technical differences depend on what the source supplied. An absent before value cannot establish that the prior configuration matched the current one. The collector retains up to 40 property entries per Resource Graph row, and string values can be cut at 1,500 characters. The Technical Diff view initially displays 50 events, with Show more available.
Raw content helps examine provenance, but “raw” is not a promise of the untouched Azure response. It is fetched on demand and represents the collector's retained payload. Resource Graph raw data omits the original changes map; the CLI Activity Log path projects selected fields. An export cannot restore information that collection did not retain.
Dependency Impact can suggest where to look next, but its roles and possible-impact text come from resource type and name heuristics. It is not a measured runtime graph. For Booking, validate the actual request path and relevant telemetry through the appropriate Azure and application sources.
Finally, the drawer's Diff & revert label does not execute a reversal. Hints are copy-only. Any proposed correction belongs in the owning service's approved change process, after checking current state. Returning the timeout to its previous value would itself be a new operational decision, not a consequence the comparison screen has authorized.
Compare the activity, not an imagined resource lifecycle
A second saved Change Explorer run can answer a different question: how did the retained activity differ between two windows? Perhaps the Booking team wants to contrast a baseline release window with the window containing the timeout update. Compare is useful when those boundaries and source conditions are understood.
Check the scope, duration, source status, and collection limits of both runs first. A broader subscription selection or a newly available source can create a large apparent difference without a comparable change in operational behavior. Describe those differences rather than treating every increase as a new problem.
The comparison's Added and Removed resources refer to membership in the runs' event sets. A gateway appearing only in the later run means its retained change activity appears there and not in the earlier set. It does not prove that the gateway was physically created. Likewise, absence from the later event set does not prove deletion.
Changed in both means that events occurred in both windows. It does not establish that the same property changed twice, that an earlier change was undone, or that the later configuration is healthy. Return to the individual events and technical differences for those questions.
A good Booking comparison might therefore yield a restrained observation: the later event set includes the timeout update, while the earlier comparable set does not. That helps organize the chronology. The causal question still requires telemetry, request-path context, and the reason for the release action.
Pin useful events and add investigator notes to the run's embedded case file, but preserve its identity separately. Copy link includes an event reference, not a complete saved-run and scope reference. A colleague may need to select the same context and load the same run before reopening the event. Record the run ID, event ID, window, and scope together so the handoff does not depend on a browser's current state.
Preserve a snapshot with an explicit purpose
Once the question is bounded, Evidence Locker provides a place to preserve selected material. The objective is not to capture every available section. It is to retain the evidence needed to reconstruct the review while avoiding unnecessary operational detail.
The capture instructions below describe a proposed Booking workflow; the animations open existing synthetic snapshots rather than capture new ones.
For Booking, that might mean inventory with full properties for the gateway context, relevant saved findings, and available recent changes. Explain each selection in the case. A snapshot called “Booking gateway configuration review” communicates intent more clearly than “full incident evidence,” particularly when the collection cannot support that broader description.
Choose workload, subscription, or explicit-resource scope deliberately. Workload capture uses the workload's own connection; subscription and selected-resource capture use the default connection, not a page-level tenant picker. Capture creates application evidence and can read Azure. It does not change the Azure resources being examined.
The scope needs inspection after capture as well as before it. Inventory retains up to 1,000 matching Resource Graph resources, and this path does not apply per-membership workload exclusions. Verify the resource list independently. Full properties adds properties, SKU, and kind to that inventory payload; the Properties tab is not a separate guarantee that everything was collected.
Recent changes requires particular care. It can retain up to 200 changes from the last 14 days, but the current query checks that scope resolved without applying the workload or resource predicate. Do not assume every retained change concerns Booking. Examine target IDs before treating the section as scoped evidence, and consider omitting it when its broader contents are unnecessary or unsuitable to retain.
Findings have a different freshness boundary. For workload capture, they come from selected recent successful assessments and active waivers; capture does not launch a new assessment. Architecture, memory, and activity likewise draw on saved application records. A new bundle can therefore contain older observations.
The Key metrics window selection currently produces an empty metrics collection with an explanatory note. It does not supply the latency evidence required by this story. Preserve relevant measurements through an appropriate source workflow, recording their window and context separately.
After capture in an authorized environment, inspect the section notes and scope information, then record the snapshot ID, creation time, relevant source timestamps, and digest. If the bundle has the wrong scope or missing prerequisites, create a corrected snapshot rather than expecting the existing one to refresh. Preservation is valuable precisely because it fixes what was captured, including its limitations.
Read the digest as a consistency check
Evidence Locker records a SHA-256 digest for the snapshot's stored content. When you open the detail or request an export, the application checks that digest. This makes unexpected modification detectable at those verification points and gives a reviewer a concrete property to examine alongside the content.
The boundary matters: content-tab, diff, and shared-content requests do not independently perform that check. Do not describe every read as cryptographically verified. Open the originals through the detail path, inspect the verification result, and check the export's verification metadata when preparing a handoff.
For Booking, keep the snapshot ID and digest together. A digest without the intended object and collection context is a weak reference. The JSON export includes metadata, content, and sha_verified, allowing a reviewer to inspect what was preserved and the reported verification outcome. This is a JSON bundle, not a ZIP package or an import-and-replay workflow.
Write-once content also differs from unchangeable metadata. Sharing and attachment actions can update snapshot metadata without rewriting its content or digest. A stable digest does not assert that no administrative action occurred around the bundle; it concerns the content being checked.
Most importantly, consistency is not source truth. A perfectly consistent snapshot can preserve an incomplete result, an out-of-scope resource, stale findings, or a mistaken upstream value. Its digest does not certify completeness, prove causation, authenticate a human's intent, or establish a legal-grade chain of custody. Those questions require their own controls and evidence.
If verification fails, stop relying on the bundle and investigate the mismatch. Preserve the relevant audit context and obtain a new snapshot from authoritative sources as appropriate. Do not resolve the inconsistency by copying the displayed hash into a case note and treating the note as a substitute for verification.
The benefit is precise: the team gains a checkable record of captured content, not a universal seal of correctness.
Compare inventory and findings on equal terms
Evidence comparison asks a different question from Change Explorer comparison. Instead of comparing activity across saved runs, it compares the retained inventory and findings in two snapshots. That makes it useful for examining a before-and-after record, provided the snapshots are genuinely comparable.
Select the intended baseline first and the later snapshot second, then use Diff selected. Confirm the direction in the comparison heading. Check both IDs, scope, inclusion choices, collection notes, and source times before interpreting a delta. Selecting a third snapshot keeps the last two selections, so the heading is worth reading even when the choices seemed obvious.
Open an existing synthetic snapshot, then compare the receipts resource's CostCenter field: DEMO-OLD → DEMO-42. The findings remain unchanged; inspect them alongside the inventory difference rather than interpreting this example as a finding being fixed.
Inventory comparison can show additions, removals, and top-level field differences. Finding comparison can show status and severity changes. Large field values are abbreviated in the diff, so inspect the original content when detail matters. Use the gateway's technical change evidence for the timeout observation rather than assuming a broad inventory difference isolates that property.
An inventory addition means the resource appears in one captured set and not the other. Before calling it a real resource creation, reconcile scope and collection completeness. A finding status change similarly needs assessment context: were both observations produced by comparable checks against the intended workload, or does the later bundle merely contain a different saved assessment?
Only inventory and findings participate in this comparison. An empty diff says nothing about memory, activity, architecture, or other sections. It certainly does not mean latency is unchanged; the metrics placeholder cannot support that conclusion.
For Booking, the comparison's role is to support the record around the hypothesis. It can establish which retained inventory fields and findings differ, expose mismatched evidence boundaries, and direct attention to originals. It cannot turn a configuration comparison into a performance test. Keep the missing measurement visible instead of allowing a reassuringly empty panel to close the question.
Put the reasoning in a separate case
Case Files gives the investigation a durable narrative beyond a particular run or chat. In an authorized investigation, create a focused title and severity, then use the opening note to state the reported impact, known facts, unknowns, accountable owner, and verification criteria. The creation form supplies title and severity only; it is not a comprehensive incident-intake form.
For Booking, the first note should distinguish the observed timeout difference from the unverified latency relationship. It should identify the review window, the selected source evidence, and the next question for the gateway owner. A later reader should not need to reverse-engineer the team's uncertainty from a confident case title.
Open an existing synthetic case, review its timeline and artifact references, and type a note draft. The draft is not submitted or persisted; this animation illustrates preparing a handoff, not saving a note or creating a case.
Association is explicit, not automatic. Change Explorer's embedded notes stay with its run. Evidence Locker's Attach to RCA records an attachment marker in snapshot metadata; it does not select or update a particular case or RCA document. To connect the evidence to the case, record snapshot and event IDs in a note or use an authorized Case Files attachment integration.
Structured attachments support finding UIDs, change-event IDs, and evidence-snapshot IDs. The UI displays those identifiers rather than opening them as links. Accepted references are not proof that the sources exist or belong to the expected context, so verify each one independently. Include the Change Explorer run identity where necessary to make the event recoverable.
Ownership can be recorded in the timeline. Assignee and other structured metadata can be populated by an authorized API integration; the detail view has no metadata editor or attachment picker. Use a note to make responsibility explicit while any separate integration work is arranged.
The supported statuses, open, investigating, remediating, verifying, resolved, and closed, organize work. They do not perform it. Move to allows transitions in either direction, and the backend does not require verification evidence before resolution. A resolved case is therefore a recorded decision, not a verified result.
For Booking, assign the gateway owner to confirm the setting's current value and affected request path, and the application owner to compare request and dependency telemetry around the reported symptom and change. Evidence that latency preceded the update would challenge the simplest causal story; timing alone would still not settle it. Any remediation needs approved success criteria and subsequent source checks.
If the timeout was unrelated, document why and what evidence changed the assessment. If uncertainty remains, say so. The append-only timeline supports that honesty: correct an earlier statement with a new note rather than trying to erase the investigative path.
Keep handoffs useful without widening exposure
Preservation is incomplete if nobody can retrieve the right record, or if sharing exposes more than intended. Change Explorer exports read the saved run, not current table filters, timeline selection, or pins. A neatly filtered gateway view does not make the exported artifact gateway-only. Inspect the download and minimize or redact it before distribution.
Do not rely indefinitely on run history. New saves keep at most 30 active runs per workload or subscription key, and older active runs can be removed rather than moved to Trash. Preserve required material under the organization's evidence policy before it ages out.
Evidence sharing is also narrower than “public link.” The UI displays a token and expiry; shared APIs require authentication and evidence.read. Token resolution is not bound to the caller's tenant, so possession should not be treated as same-tenant isolation. There is no UI revocation control, and Trash does not invalidate a still-valid token. Share only through an approved channel with intended recipients.
Ticket actions have real external consequences outside this fictional walkthrough. Evidence Locker's Attach to ticket creates a new ticket containing metadata and SHA through an enabled connector; it does not append the full blob to an existing ticket. Selecting the connector sends immediately. Case creation and generated ServiceNow text are not automatic ticket delivery.
Retention labels need policy behind them. Evidence Locker's standard and audit labels are not an enforced deletion schedule or legal hold; audit-class snapshots can still be manually purged. Case Files has no Trash, restore, or purge control. Its Delete action hides the case while the backend retains it, so neither recovery nor physical erasure should be inferred.
Separate Azure reads, application writes, and external writes when assigning permissions. changeexplorer.read permits stored investigation changes; evidence capture needs evidence.write, and case notes or attachments need cases.write. “Read-only Azure investigation” does not mean nothing is stored or sent elsewhere.
Before handing over, name the next reviewer, agree a review time, and state the evidence expected at that checkpoint. Distinguish a request to investigate from a request for an approved configuration change. Ask the recipient to acknowledge ownership and report access gaps while the current investigator is still available. Leave one explicit next decision, so the next shift can continue the review instead of reconstructing why it began.
How it's judged
The test is whether another operator can recover the evidence and understand the decision without accepting an AI summary, a risk label, or a case status as proof. That is a stronger standard than a persuasive narrative or a full-looking dashboard.
First, the change must be identifiable. The reviewer should recover the gateway resource, relevant setting, event and run references, time zone, and available before-and-after values. Actor information should retain its source and uncertainty. A friendly name alone is not enough to reproduce attribution.
Second, the evidence boundary must be visible. The record should explain which subscriptions and resources were examined, which sources were successful or unavailable, and which caps or scope differences affect interpretation. Empty results should not silently become negative findings. Fresh collection time should not disguise older saved assessment content.
Third, the preserved material must be inspectable. Snapshot IDs, originals, digests, relevant source times, and export verification results should agree with the case references. Comparison direction and inclusion choices should be explicit. A digest mismatch, unexpected resource, or stale finding should become a review issue rather than disappear into a summary.
Fourth, the reasoning must remain testable. For Booking, the documented configuration change is one observation. The causal hypothesis requires other evidence. State what would support it, what would contradict it, and who owns obtaining that evidence. An explanation that cannot accommodate disconfirmation is not yet a useful investigation record.
Finally, resolution needs an operational basis. Record approved actions, relevant subsequent observations, and the reason success criteria were met, or why the hypothesis was rejected. Confirm persistence and source state in the actual authorized workflow before making completion claims. This synthetic walkthrough demonstrates the structure of that review, not that any of those outcomes occurred.
Judge this exercise by the quality of the handoff, not a stopwatch. The useful result is a record whose observations, limitations, and decisions can withstand a second reading.
Read first, then preserve one bounded hypothesis
Start with the current Change Explorer guide, especially its scope, source limits, export behavior, and AI trigger. Then read Evidence Locker for capture and verification boundaries, and Case Files for the controls that actually exist. Read before opening an unanalyzed event or initiating capture, sharing, or connector actions.
For platform background, Microsoft's Azure Monitor Activity Log overview and Azure Resource Graph resource changes guidance explain the evidence these workflows build on. The current Azure Support Agent repository provides the project and deployment context. These tools complement Azure's native investigation capabilities and your established change process.
In an approved environment, choose one known change and a narrow review window. Establish its source visibility, inspect the available property evidence, and write down a hypothesis before reaching for a conclusion. Preserve only the necessary content, verify it through the documented paths, and record the references and remaining questions in a case.
Ask a colleague to recover that record without your browser session. Can they identify the change, explain the actor uncertainty, inspect the captured scope, and tell what still needs verification? That is a useful first exercise, without changing Azure configuration or sending a ticket notification.
The Booking timeout may ultimately explain part of the latency story, or it may not. The investigation becomes valuable when either conclusion can be supported, reviewed, and preserved, not when the first plausible explanation is promoted to fact.
