Part 4: Trace an Azure Function Incident

Trace an Azure Function incident using metrics, request logs, alerts, and KQL.

Introduction

30 Second Summary

When an online service misbehaves, a green status page can still leave you guessing. You need evidence that shows whether the problem affects everyone, one resource, or one request.

In this project, you will create a temporary HTTP endpoint with Azure Functions. You will trace its activity from broad Azure health signals to request-level evidence in Azure Monitor.

What You'll Build

Your live endpoint will turn each browser call into an evidence trail that ends with a chart of its real response times.

By the end of this project, you'll have:

A monitored HTTP endpoint that returns a successful response. Its execution chart proves Azure Functions processed your calls.
A request-level investigation using Application Insights plus Log Analytics. A Kusto Query Language chart shows how response time changes across the calls.
A proactive incident workflow with a tested email action group plus an enabled Azure Service Health alert. Your six-part triage map routes each incident question to the right Azure view.
Secret Mission: Build a reusable two-tile Azure dashboard that shows request count beside average response time.

Are there any prerequisites?

You need a Windows computer plus an active Azure subscription with permission to create monitoring resources, a Function App, an action group, and alert rules.

The setup verifies Microsoft Edge and Windows Notepad before the lab starts.

Before We Start

This opening checkpoint locks in the endpoint you will investigate before the hands-on work begins. You will trace its incident evidence from broad Azure health signals to individual request behavior.

Set Up an Isolated Monitoring Workspace

Trustworthy Azure Monitor incident evidence needs a clean source. Existing resources can mix this lab's telemetry with unrelated workloads.

You will inventory existing resources before creating a dedicated resource group. A linked Log Analytics workspace plus Application Insights gives the lab one clean investigation boundary.

In this step, get ready to:

Inventory existing monitoring resources in the selected subscription.
Create a dedicated Log Analytics workspace inside the lab resource group.
Link Application Insights to the workspace.

Inventory existing monitoring resources

An inventory separates resources that already belong to your subscription from the resources created for this lab. This baseline keeps your investigation focused.

In Microsoft Edge, find Log Analytics workspaces by entering Log Analytics workspaces in the portal search.
Select Log Analytics workspaces from the search results.
Review the list to determine whether the selected subscription already contains any workspaces.
Find Application Insights by entering Application Insights in the portal search.
Select Application Insights from the search results.
Review the list to determine whether the selected subscription already contains any Application Insights resources.

Good work. You now have a baseline that prevents existing monitoring resources from being mistaken for lab resources.

Switch back to Windows Notepad.
Place the cursor at the end of Documents\monitoring-triage-map.txt.
Press Enter twice to insert a blank line.
Add this exact inventory note: Existing monitoring-resource inventory: existing Log Analytics workspaces and Application Insights resources found in the selected subscription were recorded before creating this isolated lab.
Press Ctrl+S to save Documents\monitoring-triage-map.txt.

Your triage map now preserves the pre-lab baseline beneath the initial incident note.

Create the isolated resource group and workspace

The resource group keeps the observability resources under one lifecycle. You can review or remove the complete monitoring lab without touching unrelated workloads.

Find Resource groups by entering Resource groups in the portal search.
Select Resource groups from the search results.
Select Create.
Confirm that Subscription shows the intended subscription.
Enter rg-monitoring-lab-observability in Resource group.
Select one supported Azure location in Region.
Select Review + Create.

You should see the resource group settings pass validation.

Azure usually creates a resource group within a few seconds, so a brief pause is expected.

Select Create.
Select Refresh after creation completes.

You will see rg-monitoring-lab-observability in the resource group list.

Record the region you chose here: your selected Azure region.

Why Isolate the Lab?

Resources with the same lifecycle belong together. This resource group gives the lab a clear boundary for deployment and cleanup.

The workspace collects this lab's telemetry for analysis. It also gives Application Insights a dedicated data destination.

How Workspace Costs Begin

Portal creation applies the default pay-as-you-go tier. No charges accrue until data collection begins.

Later ingestion can create usage charges. You stay in control because this isolated workspace is easy to identify during cleanup.

Find Log Analytics workspaces by entering Log Analytics workspaces in the portal search.
Select Log Analytics workspaces from the search results.
Select Create.
Confirm that Subscription shows the intended subscription.
Select rg-monitoring-lab-observability in Resource Group.
Enter law-monitoring-lab as the workspace name.
Set Region to your selected Azure region.
Select Review + Create.

You should see the workspace settings pass validation.

Azure may need a short while to deploy the workspace. A brief wait here is expected.

Select Create.
Wait for the deployment to complete.
Return to Log Analytics workspaces by using the portal search.
Select Refresh.

You will see law-monitoring-lab listed inside rg-monitoring-lab-observability.

Workspace Deployment Missing?

Confirm that the portal still shows the intended subscription.
Check the portal notification area for a deployment failure caused by permissions or regional availability.
Still stuck? Help me troubleshoot my Log Analytics workspace deployment.

Link Application Insights to the workspace

Workspace-based Application Insights stores its telemetry in a linked Log Analytics workspace. This connection lets later request evidence appear in one dedicated query destination.

Select Create a resource from the Azure portal menu.
Select Monitoring & Diagnostics.
Select Application Insights to reach its creation form.
Confirm that Subscription shows the intended subscription.
Select rg-monitoring-lab-observability as the resource group.
Enter appi-monitoring-lab as the resource name.

The form now scopes the new monitoring resource to the isolated lab group.

Set Region to your selected Azure region.
Choose law-monitoring-lab as the linked Log Analytics workspace.
Select Review + create.

You should see the Application Insights settings pass validation.

The deployment can take a short while while Azure connects both monitoring resources.

Select Create.
Wait for the deployment to complete.
Find appi-monitoring-lab by entering its name in the portal search.
Select appi-monitoring-lab from the search results.

Before opening the Workspace link, which resource do you expect the portal to show?

On the Application Insights Overview page, select the blue link beside Workspace.

You will land on law-monitoring-lab. This proves that appi-monitoring-lab sends its telemetry to the isolated workspace.

That is the monitoring foundation in place. Your application telemetry now has a dedicated home.

Workspace Link Incorrect?

Confirm that you selected appi-monitoring-lab from the search results.
Check that the linked workspace shown on its Overview page is law-monitoring-lab.
Still stuck? Help me verify the Application Insights workspace link.

Your isolated monitoring workspace is ready. Next, you will launch the HTTP endpoint that generates the telemetry for your investigation.

Launch the Incident Target

Your isolated Log Analytics workspace now has a linked Application Insights resource. Together, they give the lab a clean telemetry destination.

Azure Functions gives the investigation a real endpoint that can generate activity. The app uses Windows Consumption with Node.js 24 for a browser-only creation path in the Azure portal.

In this step, get ready to:

Create a Windows Consumption Function App in a separate resource group.
Connect the Function App to the existing Application Insights resource.
Create an anonymous HTTP trigger that produces invocation trace output.

Configure the Function App

A separate resource group keeps the temporary application resources away from the monitoring resources. This boundary also makes cleanup predictable.

Why Windows Consumption?

Flex Consumption is the usual starting point for new serverless apps. It does not support in-portal editing.

Windows Consumption supports the browser-only path used in this lab. This keeps your attention on monitoring instead of local development.

Return to the Azure portal tab from earlier.
Enter Function App in the portal search bar.
Select Function App from the search results.
Select Create.
Choose Consumption.
Select Select.

The creation form now targets the Windows dynamic hosting option used by this lab.

Confirm the intended subscription.
Create a new resource group named rg-monitoring-lab-app.

The form now isolates the Function App from rg-monitoring-lab-observability.

Set Region to the same lab region you used earlier.
Enter a globally unique name using this pattern: fn-monitor-lab-<unique-name>.
Wait for the name field to confirm that your Function App name is available.

Your selected name becomes the addressable identity of the Function App. Azure requires this name to be globally unique.

Select Node.js as the runtime stack.
Select 24 as the Node.js version.

The runtime settings now show Node.js 24.

Select Windows as the operating system.
Confirm that the hosting option still shows Consumption.

The app configuration now matches the browser-editable Function App required for this investigation.

Connect monitoring and create the app

Every Function App requires an Azure Storage account. This storage is billed separately from the Functions grant.

Creating billable resources can feel risky. The cleanup section gives you a direct path to delete the lab when you finish.

Keep the option that creates a new storage account for the Function App.
Select the Monitoring page.
Keep Application Insights enabled.
Choose the existing appi-monitoring-lab instance.
Confirm that the Application Insights selection shows appi-monitoring-lab.

The wizard now points the Function App at the monitoring resource linked to law-monitoring-lab.

Select Review + create.

What should the summary show?

The resource group shows rg-monitoring-lab-app.
The hosting option shows Consumption.
The operating system shows Windows.
The runtime shows Node.js 24.
The monitoring selection shows appi-monitoring-lab.
The storage configuration shows a new required storage account.

Select Create.

Provisioning can take a few minutes. A quiet deployment screen during that time is normal.

Wait until the deployment reports completion.
Return to the Function App Overview page.
Select the rg-monitoring-lab-app resource group link.
Confirm that the resource group lists your Function App plus its required storage account.
Return to your Function App Overview page.

Good progress. Your incident target now has the hosting resources plus the monitoring connection it needs.

Function App deployment not completing?

Check whether Azure rejected the Function App name because another app already uses it. Enter a different globally unique name with the same prefix.
Confirm that your subscription permits resource creation in the selected region.
Return to the review summary if the runtime or operating system differs from the required configuration.
Still stuck? Help me troubleshoot my Azure Function App deployment.

Create and test the HTTP trigger

An HTTP trigger turns the Function App into the endpoint for this incident investigation. Anonymous authorization lets the lab call the endpoint without credentials.

Find the Functions section on the Function App Overview page.
Select + Create.
Choose the HTTP trigger template.
Enter HttpExample in the New Function field.
Set Authorization level to Anonymous.
Select Create.

You should now see HttpExample in the Function App's Functions list.

Missing the portal create option?

Confirm that the app uses Windows with the Consumption plan.
Confirm that the runtime stack is Node.js 24.
Refresh the Function App Overview page after checking the configuration.
Still missing + Create? Help me check whether my Function App supports in-portal function creation.

Select HttpExample from the Functions list.
Expand Developer.
Select Code + Test.
Select Test/Run.

Before you run the function, do you expect the anonymous HTTP trigger to complete successfully?

Select Run.
Expand Logs.

The result area reports a successful invocation. The Logs pane shows trace output for that invocation.

Select Run several more times.
Watch the Logs pane after the final invocation.

Each invocation produces a successful result. The latest invocation adds visible trace output to the Logs pane.

No successful result or trace output?

Confirm that HttpExample is selected before using Test/Run.
Expand the Logs pane before running the function again.
Still stuck? Help me test HttpExample and find its invocation trace output.

That is the first live win of the investigation. Your endpoint now runs successfully plus produces monitoring data.

Next, you will test what broad Azure health views can prove about this active Function App.

Triage Platform Health and Metrics

Your HttpExample endpoint is running. Its earlier invocations have produced monitoring data.

Incident triage starts by narrowing the scope of the problem. In this step, you will compare Azure health signals with resource activity before deciding what evidence is still missing.

In this step, get ready to:

Compare global Azure Status with personalized Service Health.
Record the Function App's Resource Health state.
Compare Function Execution Count with the health evidence.

Check global and subscription health

An incident can affect all Azure customers or only resources tied to your subscription. Azure Status covers widespread incidents.

Azure Service Health personalizes issue information for your subscription. It also narrows that evidence to the selected region.

Visit the Azure Status page in Microsoft Edge.
Determine whether the page reports a widespread incident.
Switch back to the Azure portal tab from earlier.
Enter Service Health in the portal search bar.
Select Service Health from the search results.
Select Service Issues.
Determine whether any personalized issue affects your subscription or selected region.

Good progress. You have separated widespread Azure incidents from events personalized to your subscription.

How Do the Health Views Differ?

Azure Status reports widespread incidents across the Azure platform.

Service Health filters health information to your subscription. Region selection narrows that evidence further.

Switch back to monitoring-triage-map.txt in Windows Notepad.
Add a section named Platform triage evidence.
Record whether Azure Status showed a widespread incident.
Record whether Service Health showed a subscription or selected-region event.

Inspect Function App resource health

Resource Health moves the investigation from your subscription to one Azure resource. Its displayed state tells you whether Azure has detected an event affecting your Function App.

Return to the Azure portal tab from earlier.
Enter your Function App name in the portal search bar.
Select your Function App from the search results.
Select Resource health from the resource menu.
Identify the displayed health state.
Read the explanation shown for that state.

You'll see one documented state: Available, Unavailable, Unknown, or Degraded. The accompanying explanation provides the resource-specific context for that state.

Switch back to monitoring-triage-map.txt in Windows Notepad.
Record the displayed Resource Health state under Platform triage evidence.
Record the explanation shown for the state.

Resource Health Pane Not Loading?

Confirm that the resource heading shows your Function App name.
Confirm that the intended Azure subscription remains selected.
Still stuck? Help me troubleshoot Resource Health for my Azure Function App.

Compare platform metrics with health evidence

Azure Monitor metrics measure resource activity over time. Function Execution Count counts Function App executions.

The Sum aggregation adds the executions represented in the chart. This creates activity evidence that you can compare with the health findings.

Switch back to your Function App in the Azure portal.
Select Monitoring in the resource menu.
Select Metrics.

Before you choose the metric, can an execution count explain what happened inside each HTTP request?

Select Function Execution Count in the Metric field.
Select Sum in the Aggregation field.

You should see execution data in the chart. That activity proves the Function App processed invocations during the displayed period.

No Execution Data in the Chart?

Confirm that the selected metric is Function Execution Count.
Change the chart period so it includes the earlier successful HttpExample runs.
Still stuck? Help me find my Function Execution Count data.

Inspect the chart for individual request success information.
Inspect the chart for individual result codes.
Inspect the chart for individual request durations.

You'll find resource-level execution counts only. The chart does not reveal which HttpExample calls succeeded. It also lacks their result codes and durations.

What Did the Metric Prove?

Function Execution Count confirms that the Function App processed activity during the selected period.

Per-request behavior remains unresolved. The investigation still needs evidence about success, result codes, and response time.

Switch back to monitoring-triage-map.txt in Windows Notepad.
Record that Azure Monitor Metrics shows Function Execution Count with Sum aggregation.
Record that the chart contains execution data.
Finish the section with this unresolved question in your own words: which HttpExample calls succeeded, which result codes they returned, and how long they took.
Return to the Metrics chart in the Azure portal.

You should still see execution data for Function Execution Count with Sum selected. The chart proves activity while preserving the request-level visibility gap you just identified.

You've exposed the exact gap in platform-level evidence. Next, you'll trace individual calls with request telemetry to find their result codes and durations.

Trace Requests with Application Insights and KQL

Your Azure Monitor chart proved that the Azure Functions target is active. It also exposed the investigation gap: execution counts cannot show what any individual request returned.

Application Insights shows telemetry close to each invocation. The linked Log Analytics workspace exposes the same telemetry as structured records.

Kusto Query Language turns those records into a response-time chart. That evidence closes the request-level gap.

In this step, get ready to:

Inspect an invocation from HttpExample.
Review request telemetry in Application Insights.
Query AppRequests data with KQL.

Inspect one function invocation

The invocation history connects the execution count to individual function runs. Each row gives you a specific event to investigate.

Telemetry is batched, so invocation records can take up to five minutes to arrive. A short wait here is expected while the telemetry client sends its next batch.

Return to the Function App from earlier in the Azure portal.
Select Functions in the left menu.
Select HttpExample from the function list.
Select Monitor.
Select Refresh.
Wait up to five minutes if the invocation table is empty.
Select Refresh again.
Select the Date (UTC) link for one invocation.

You'll see details for one specific invocation. This proves that the execution count represents individual function runs.

What does one invocation prove?

The invocation details narrow your evidence from resource activity to one function run. Application Insights provides wider views for comparing that run with the application's telemetry.

Return to appi-monitoring-lab.
Select Failures to check for failed request operations.
Select Performance to compare request duration evidence.
Select Metrics to identify available request measurements.
Select Live Metrics to check whether telemetry is currently flowing.

You now have several application-level views of the same workload. The next query exposes the underlying request records directly.

No Invocation Records Yet?

Wait up to five minutes for the telemetry batch to arrive.
Select Refresh again after the wait.
Generate another successful invocation with the same Test/Run workflow from earlier.

Still stuck? Help me find missing Azure Functions invocation telemetry.

Query request records in Log Analytics

The linked workspace stores Application Insights request telemetry in the AppRequests table. Querying that table reveals the fields missing from the execution-count chart.

Return to the Overview page for appi-monitoring-lab.
Select the Workspace link.
Select Logs in law-monitoring-lab.
Switch to KQL mode if the query editor is using another mode.
Replace the current query text with this KQL query:

AppRequests

What Does This Query Do?

The AppRequests table stores request telemetry sent from Application Insights.
Running the table name alone returns request records without adding filters or calculations.

Predict which request-level fields the table will reveal.
Select Run.
Inspect the results table for Name, Url, DurationMs, ResultCode, and Success.

You'll see request rows generated by HttpExample. That is the gap closed: you can now inspect what each request did.

No AppRequests Rows?

Confirm that the query scope shows law-monitoring-lab.
Generate another successful invocation with the same Test/Run workflow from earlier.
Wait up to five minutes for the new telemetry batch.

Still stuck? Help me troubleshoot missing AppRequests records.

Chart average response time

Individual rows explain single requests. A time chart reveals how average response duration changes across the last twelve hours.

Replace the current query with the official response-time trend query:

// To create an alert for this query, click '+ New alert rule'
AppRequests
| where TimeGenerated > ago(12h)
| summarize avgRequestDuration=avg(DurationMs) by bin(TimeGenerated, 10m), _ResourceId // use a time grain of 10 minutes
| render timechart

How Does the Trend Query Work?

The where TimeGenerated > ago(12h) line limits the evidence to the last twelve hours.
The avg(DurationMs) calculation finds the average request duration.
The bin(TimeGenerated, 10m) expression groups requests into ten-minute time bins.
The render timechart line turns the summarized values into a chart.

Predict whether the average response time will stay level or vary between time bins.
Select Run.

You'll see a time chart rendered from AppRequests data generated by HttpExample.

No Response-Time Chart?

Confirm that the query scope shows law-monitoring-lab.
Check that each query line matches the official response-time query exactly.
Run AppRequests again to confirm that request rows still exist.

Still stuck? Help me fix my AppRequests response-time chart.

The chart completes the request-level investigation. Your incident map now needs the evidence that resolved the visibility gap.

Switch back to Documents\monitoring-triage-map.txt in Windows Notepad.
Append this request telemetry evidence:

Request telemetry evidence: HttpExample invocation details and Application Insights views were inspected. law-monitoring-lab AppRequests records expose Name, Url, DurationMs, ResultCode, and Success. The response-time KQL query rendered a time chart.

Why Record This Evidence?

This note captures which monitoring layer answered the unresolved request questions. It gives your future incident workflow a clear handoff from platform metrics to request telemetry.

Save Documents\monitoring-triage-map.txt.
Return to the Logs page from earlier.
Confirm that the response-time chart remains visible.

That closes the investigation. You can now move from a broad health signal to the duration of individual requests.

Your request evidence now explains what the broad health views could not. Next, you'll add proactive notifications and complete your incident-triage map.

Add Alerting and Close the Incident

Your investigation now reaches the request evidence that broad health views could not provide. You can explain how the function behaved during the reported issue.

The response remains reactive until Azure can notify you about future service events. Azure Monitor alerting closes that gap with a tested notification path.

In this step, get ready to:

Create a verified email action group with a successful sample test.
Enable a Service Health alert for future subscription events.
Complete the incident routing map with an Azure Advisor finding.

Create and test the email action group

An action group is a reusable notification target for Azure alerts. It stores the email path that your Service Health rule uses.

Switch back to the Azure portal tab in Microsoft Edge.
Select Monitor from the portal menu.
Select Alerts.
Select Action groups.
Select Create.
Choose the intended subscription in Subscription.
Choose rg-monitoring-lab-observability in Resource group.
Set Region to Global.

Why Is Global Required?

Service Health alerts operate in the global region. Their action groups must also use Global so Azure can route subscription-level event notifications.

The email check uses a one-time passcode. It only verifies that you control the notification address.

Enter ag-monitoring-lab in Action group name.
Enter monitorlab in Display name.
Select Notifications.
Select Email as the notification type.
Enter an email address that you can check now.
Enter Email in the notification name field.
Complete the one-time passcode verification when Azure sends the verification message.

Your email receiver is now verified for alert delivery. The verification must be completed within 30 minutes of saving.

Select Review + create.
Select Create.

That is the first proactive link in place. Your alerting workflow now has a reusable email destination.

Before you send the sample, do you think the portal result and your inbox will both confirm the notification path?

Select ag-monitoring-lab from the Action groups list.
Select Test.
Choose the Service Health sample sample type.
Choose the Email notification type.
Select Test to send the sample.

The portal should report Success for the test.

Check your email inbox for the newest notification.

The email subject should contain Test. Your notification path now works from Azure to your inbox.

Didn't Receive the Test Email?

Confirm that the email receiver completed its one-time passcode verification.
Check the junk folder for the test notification.
Run the action-group test again after the receiver shows as verified.
Still stuck? Help me troubleshoot the action-group email test.

Create the Service Health alert

A Service Health alert watches for personalized events that affect your subscription. It turns the action group into a notification workflow for future service issues.

Service Health alert rules are free of charge. The first 1,000 email notifications each month are included.

Select the Azure portal search bar.
Enter Service Health.
Select Service Health from the results.
Select Service Issues.
Select Create service health alert.
Choose the intended subscription under Scope.
Select every option under Services.
Select every option under Regions.

Why Select Every Service and Region?

Service Health only triggers the rule when an event affects your selected scope. Covering all services and regions keeps the rule useful when your Azure footprint changes.

Select Service issue under Event types.
Select Planned maintenance under Event types.
Choose ag-monitoring-lab as the action group.
Choose rg-monitoring-lab-observability in Resource group.
Enter alert-service-health-lab as the alert rule name.
Select Create.
Select Health alerts in Service Health.
Locate alert-service-health-lab in the alert list.

You should see the new Service Health alert listed as enabled. Azure can now notify your verified email path about matching events.

Can't Find the New Alert?

Refresh Health alerts after the creation process finishes.
Confirm that the alert was stored in rg-monitoring-lab-observability.
Check that the intended subscription remains selected in the portal.
Still stuck? Help me find my Service Health alert.

Finish the incident routing map

A useful incident map sends each question to the narrowest tool that can answer it. Azure Advisor adds personalized recommendations based on your current configuration and usage.

Your Six-Part Routing Map

Global outage: Azure Status.
Subscription or regional event: Service Health.
Individual resource state: Resource Health.
Resource activity: Azure Monitor Metrics.
Request behavior: Application Insights plus Log Analytics.
Proactive notification: Azure Monitor alerts.

Switch back to Windows Notepad.
Move the cursor below the request telemetry evidence in Documents\monitoring-triage-map.txt.
Add the six mappings from the routing map callout.
Save Documents\monitoring-triage-map.txt.

Switch back to the Azure portal.
Select the portal search bar.
Enter Azure Advisor.
Select Azure Advisor from the results.
Select Reliability to identify any recommendation that applies to the lab.
Select Security to identify any recommendation that applies to the lab.
Select Performance to identify any recommendation that applies to the lab.
Select Cost to identify any recommendation that applies to the lab.

You have checked four recommendation categories. One final category completes the Advisor review.

Select Operational excellence to identify any recommendation that applies to the lab.

What the Advisor Note Captures

The note records that you reviewed Reliability, Security, Performance, Cost, plus Operational excellence. It includes one relevant recommendation when available.

If no recommendation applies, the note records that none is currently available. That result still proves you completed the review.

Switch back to Windows Notepad.
Add the Azure Advisor review note below the completed routing map.
Save Documents\monitoring-triage-map.txt.

Before the final check, do you expect the alert list and your map to show a complete shift from investigation to proactive response?

Switch back to the Azure portal.
Select Service Health.
Select Health alerts.
Locate alert-service-health-lab.
Switch back to Windows Notepad.
Review the final two sections of Documents\monitoring-triage-map.txt.

You should see alert-service-health-lab listed as enabled. Your earlier action-group test should have reported Success.

The file should contain the complete six-part routing map. It should also contain the Advisor review with either a relevant recommendation or a no-recommendation note.

You have closed the incident loop. Your evidence now supports investigation, routing, and proactive notification for the next service event.

Secret mission

Build a Reusable Incident Dashboard

Your queries already explain how `HttpExample` behaves. Turn them into side-by-side time charts on an Azure dashboard. Generate fresh requests to prove the view is reusable.

Clean Up Your Resources

Persistent storage and monitoring usage can still create charges. Decide whether to keep the lab running, pause its activity, or delete its resources.

Cost warning

The Function App's required storage account is billed separately from the Azure Functions free grant.

Log Analytics ingestion can create charges. Retaining Application Insights data beyond 90 days can also create charges.

Disabling HttpExample leaves the storage account in place. Disabling alert-service-health-lab leaves the stored telemetry in place.

Resources you used:

The rg-monitoring-lab-app resource group containing the Azure Functions app fn-monitor-lab-<unique-name>. This group also contains HttpExample plus its required storage resources.
The rg-monitoring-lab-observability resource group containing law-monitoring-lab plus appi-monitoring-lab. This group also contains ag-monitoring-lab plus alert-service-health-lab.
The Azure dashboard containing the request-count tile plus the average-response-time tile.

Keep everything running

Keep this option if you want to continue investigating the endpoint. Your telemetry queries and incident dashboard remain available.

Leave rg-monitoring-lab-app in place so HttpExample remains available for new requests.
Leave rg-monitoring-lab-observability in place so your telemetry and alerting resources remain available.
Keep the Azure dashboard so its two telemetry tiles remain ready for future investigations.
Review any lab charges from Cost Management + Billing in the Azure portal.
Check workspace usage from Usage and estimated costs in law-monitoring-lab.

Pause - I'll come back to this later

Pausing stops new function executions and Service Health notifications. The Azure resources and stored data stay in place.

Return to fn-monitor-lab-<unique-name> in the Azure portal.
Select HttpExample under Functions.
On Overview, select Disable.
Return to Service Health in the Azure portal.
Select Health alerts.
Open alert-service-health-lab.
Disable the alert rule.

Your function no longer processes requests. Your Service Health rule no longer sends notifications.

The storage account and existing telemetry remain stored. Usage or retention charges can still apply.

Delete - I don't want to use this again

Deleting both resource groups is irreversible. These groups were created only for this lab, so review their contents before confirming each deletion.

Return to rg-monitoring-lab-app in the Azure portal.
Review the resource list to confirm that it contains only the Function App lab resources.
Select Delete resource group.
Type rg-monitoring-lab-app in the confirmation field.
Complete the deletion confirmation.

The Function App is removed with HttpExample. Its required storage resources are also removed.

Return to rg-monitoring-lab-observability in the Azure portal.
Review the resource list to confirm that it contains only the monitoring lab resources.
Select Delete resource group.
Type rg-monitoring-lab-observability in the confirmation field.
Complete the deletion confirmation.

The linked workspace and Application Insights resource are removed. The action group and Service Health alert are also removed.

Return to the Azure dashboard you created in the Secret Mission.
Use the dashboard toolbar to delete the dashboard separately.
Confirm that the dashboard no longer appears in your dashboard list.

Nice Work!

Excellent work! Your Azure Functions endpoint now supports an investigation from platform health to request-level telemetry.

You've learned how to:

Use layered incident triage to move from Azure Status through Azure Service Health to Resource Health. Confirm resource activity with Azure Monitor metrics.
Inspect request telemetry in Application Insights. Follow the same evidence into Log Analytics. Query AppRequests with Kusto Query Language to chart average response time.
Test an email notification path through ag-monitoring-lab. Enable alert-service-health-lab for future Service Health events. Capture the six-part routing map in monitoring-triage-map.txt after reviewing Azure Advisor.
Complete the Secret Mission by building a reusable Azure dashboard. Place request count beside average response time for HttpExample.

Ready to quiz yourself?