Monitoring Your First Azure Subscription: A New Subscription Checklist

The first few days with a new Azure subscription are when the most important monitoring mistakes are made — or avoided. Without a budget alert, you may not notice runaway costs until the monthly bill arrives. Without an activity log review, you cannot tell who changed what. This page gives you a practical checklist of the five monitoring steps that every new subscription should have in place, with CLI commands for each one.

Why Monitoring Setup Comes Before Everything Else

A common pattern with new Azure subscriptions: a developer starts experimenting, creates some VMs or services to test something, gets pulled away to other work, and comes back three weeks later to a bill much larger than expected. The resources were running the whole time. No one was watching.

Another common pattern: a configuration change breaks something in production. The team scrambles to understand what changed and who changed it. Without the Activity Log set up and readable, the investigation takes hours of detective work instead of minutes.

Spending 30 minutes setting up basic monitoring at subscription creation time prevents both of these scenarios. The five steps below cover the minimum viable monitoring setup for any new subscription.

Step 1: Set a Budget Alert in Cost Management

A budget alert sends you an email when your monthly spending reaches a threshold you define. It does not stop spending — Azure is not automatically gated — but it ensures you know before a surprising bill arrives at month end.

In the Portal

  1. Search for “Cost Management” in the portal search bar and open it.
  2. Make sure you are in the correct subscription scope (check the scope selector at the top of Cost Management).
  3. In the left sidebar, click Budgets, then Add.
  4. Set the budget name, period (Monthly), reset date (the 1st), and amount (your expected monthly spend, or a safety threshold like $200 for a dev subscription).
  5. On the Alerts tab, add an alert condition at 80% and another at 100% of the budget.
  6. Add an email address for notifications.
  7. Click Create.

Via CLI

Creating a budget via CLI requires the Azure Cost Management extension. Install it first if needed:

az extension add --name costmanagement

Then create a budget at the subscription level:

# Get your subscription ID
SUBSCRIPTION_ID=$(az account show --query id --output tsv)

az consumption budget create \
  --budget-name "monthly-dev-budget" \
  --amount 200 \
  --category Cost \
  --time-grain Monthly \
  --start-date 2026-04-01 \
  --end-date 2027-04-01 \
  --scope "/subscriptions/$SUBSCRIPTION_ID" \
  --notifications '[{"enabled": true, "operator": "GreaterThanOrEqualTo", "threshold": 80, "contactEmails": ["your-email@example.com"], "thresholdType": "Actual"}]'

This creates a $200 monthly budget that emails you when 80% of that amount is spent. Set the amount to match your expected spend — the goal is an early warning, not a cap.

Tip

Set two alert thresholds: one at 80% (early warning — you have time to investigate) and one at 100% (you have hit the budget — act now). A single threshold at 100% often does not leave enough time to respond before the overage compounds.

Step 2: Understand and Review the Activity Log

The Activity Log records every management operation in your subscription — every resource creation, modification, deletion, and role assignment — along with who performed it, when, and whether it succeeded. It is the first place to check when something breaks or something unexpected appears.

Activity Log data is retained for 90 days by default. After 90 days, entries are deleted. If you need longer retention for compliance or investigation purposes, configure a diagnostic setting to export the log to a Log Analytics workspace or a storage account.

Viewing the Activity Log in the Portal

  1. Search for “Activity Log” in the portal. Or, open any resource group and click Activity Log in its left sidebar to see operations scoped to that group.
  2. The log shows operations with timestamps, the user or service that performed them, the operation type (write, delete, action), and the result (succeeded, failed).
  3. Use the filters at the top to narrow by time range, resource group, resource type, or operation type.

Reading the Activity Log via CLI

# Show all activity in the last 24 hours
az monitor activity-log list \
  --start-time "$(date -u -d '24 hours ago' '+%Y-%m-%dT%H:%M:%SZ')" \
  --output table

# Show only failed operations in the last 7 days
az monitor activity-log list \
  --start-time "$(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ')" \
  --status Failed \
  --output table

# Show operations for a specific resource group
az monitor activity-log list \
  --resource-group myapp-dev-rg \
  --start-time "$(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ')" \
  --output table

Make it a habit to check the Activity Log for failed operations when deploying to a new environment or after making configuration changes. The log entries for failed operations contain detailed error messages that often explain exactly what went wrong.

Exporting Activity Log to Log Analytics for Longer Retention

# Create a Log Analytics workspace for log storage
az monitor log-analytics workspace create \
  --resource-group monitoring-rg \
  --workspace-name myapp-logs \
  --location eastus

# Get the workspace resource ID
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group monitoring-rg \
  --workspace-name myapp-logs \
  --query id \
  --output tsv)

# Create a diagnostic setting to send the subscription Activity Log to the workspace
az monitor diagnostic-settings subscription create \
  --name "activity-log-to-la" \
  --workspace $WORKSPACE_ID \
  --logs '[{"category": "Administrative", "enabled": true}, {"category": "Security", "enabled": true}, {"category": "Policy", "enabled": true}, {"category": "Alert", "enabled": true}]'

After this, subscription activity logs flow to Log Analytics where they are retained for the workspace’s configured retention period (30 days by default, configurable to up to 730 days).

Step 3: Check Resource Health

Azure Resource Health shows whether a specific resource is running, degraded, or unavailable, and distinguishes between issues caused by your configuration and issues caused by Azure platform problems. This distinction matters: if a VM is unhealthy because Azure had a hardware issue, Microsoft is working on it. If it is unhealthy because you misconfigured the OS, you need to fix it.

In the Portal

Navigate to any resource (VM, storage account, App Service), open its blade, and look for Resource health in the left sidebar. The page shows the current health status — Available, Degraded, Unavailable, or Unknown — with a history of health events. If Azure caused the issue, the event is labeled as a platform event. If you caused it, it is labeled a user-initiated event.

The subscription-level view (search for “Resource health” in the portal) shows health across all resources in a subscription, making it easy to spot any resources that are currently in a degraded state.

Via CLI

# Check health of all resources in a resource group
az resource list \
  --resource-group myapp-dev-rg \
  --query "[].id" \
  --output tsv | while read id; do
    az rest \
      --method get \
      --url "https://management.azure.com${id}/providers/Microsoft.ResourceHealth/availabilityStatuses/current?api-version=2022-10-01" \
      --query "{name: name, availabilityState: properties.availabilityState}" \
      2>/dev/null
done

Setting Up Resource Health Alerts

Resource Health can trigger an alert when a resource transitions from healthy to degraded:

# Create an action group for email notifications first
az monitor action-group create \
  --name "ops-email-group" \
  --resource-group monitoring-rg \
  --short-name "OpsEmail" \
  --action email ops-contact ops@example.com

# Create a resource health alert for all resources in the subscription
ACTION_GROUP_ID=$(az monitor action-group show \
  --name "ops-email-group" \
  --resource-group monitoring-rg \
  --query id \
  --output tsv)

az monitor activity-log alert create \
  --name "resource-health-alert" \
  --resource-group monitoring-rg \
  --scope "/subscriptions/$(az account show --query id --output tsv)" \
  --condition "category=ResourceHealth and level=Error" \
  --action-group $ACTION_GROUP_ID \
  --description "Alert when any resource becomes unhealthy"

Step 4: Enable Basic Azure Monitor Metrics

Azure Monitor automatically collects platform metrics for most Azure resources — CPU percentage, disk reads/writes, network in/out, request counts, response times — with no configuration required. These metrics are available in the portal under any resource’s Metrics blade, and are retained for 93 days.

What you need to configure explicitly are alerts based on those metrics. Metrics without alerts are data you have to check manually. Alerts tell you when something is wrong without you having to look.

Creating a CPU Alert for a VM via CLI

# Get the VM resource ID
VM_ID=$(az vm show \
  --name my-vm \
  --resource-group myapp-dev-rg \
  --query id \
  --output tsv)

# Create a metric alert: email when CPU exceeds 90% for 5 minutes
az monitor metrics alert create \
  --name "high-cpu-alert" \
  --resource-group monitoring-rg \
  --scopes $VM_ID \
  --condition "avg Percentage CPU > 90" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action $ACTION_GROUP_ID \
  --description "Alert when VM CPU exceeds 90% for 5 minutes"

Enabling Diagnostic Settings for Richer Logs

Platform metrics are automatic, but diagnostic logs (detailed resource logs that go beyond metrics) require a diagnostic setting to be enabled on each resource:

# Enable diagnostic settings on a storage account to capture read/write logs
STORAGE_ID=$(az storage account show \
  --name myappstorage001 \
  --resource-group myapp-dev-rg \
  --query id \
  --output tsv)

az monitor diagnostic-settings create \
  --resource $STORAGE_ID \
  --name "storage-diagnostics" \
  --workspace $WORKSPACE_ID \
  --logs '[{"categoryGroup": "allLogs", "enabled": true}]' \
  --metrics '[{"category": "Transaction", "enabled": true}]'

Enabling diagnostic settings on key resources sends detailed logs to Log Analytics, which you can then query with KQL (Kusto Query Language) to investigate issues. See Azure Resource Hierarchy for how resources, resource groups, and subscriptions relate to monitoring scope.

Step 5: Subscribe to Azure Service Health Alerts

Resource Health tracks whether your specific resources are healthy. Azure Service Health tracks the health of the Azure platform itself — outages, planned maintenance, and service advisories that might affect the regions and services you use.

Without Service Health alerts, you find out about Azure outages the same way as everyone else — when your resources stop working and you start searching Twitter. With a Service Health alert configured, you get an email the moment Microsoft announces an issue affecting your region and service.

Creating a Service Health Alert in the Portal

  1. Search for “Service Health” in the portal and open it.
  2. In the left sidebar, click Health alerts, then Add service health alert.
  3. Configure the scope: choose your subscription.
  4. Select services you use (Virtual Machines, Storage, App Service, etc.).
  5. Select the regions you deploy to.
  6. Select event types: Service Issues (outages), Planned Maintenance, and Health Advisories.
  7. Add your action group for email notifications.
  8. Click Create.

Via CLI

az monitor activity-log alert create \
  --name "azure-service-health-alert" \
  --resource-group monitoring-rg \
  --scope "/subscriptions/$(az account show --query id --output tsv)" \
  --condition "category=ServiceHealth and properties.impactedServices[*].ServiceName contains 'Virtual Machines' or properties.impactedServices[*].ServiceName contains 'Storage'" \
  --action-group $ACTION_GROUP_ID \
  --description "Alert on Azure platform service issues affecting VMs and Storage"

Service Health alerts are free. They take 5 minutes to set up and they prevent you from spending an hour investigating a problem that Azure is already working on.

The Complete New Subscription Monitoring Checklist

Here are all five steps condensed into a checklist. Complete these within the first day of creating a new subscription:

  1. Set a monthly budget alert in Cost Management.
    CLI: az consumption budget create —budget-name “monthly-budget” —amount [X] —scope “/subscriptions/[ID]”
    Set alert at 80% and 100% thresholds.

  2. Review the Activity Log.
    CLI: az monitor activity-log list —start-time [date] —output table
    Optional: export to Log Analytics for >90-day retention.

  3. Check Resource Health for any existing resources.
    Portal: Resource Health blade on each resource.
    Create a Resource Health alert to notify on state changes.

  4. Create metric alerts for critical resources.
    CLI: az monitor metrics alert create for CPU, disk, and response time thresholds.
    Enable diagnostic settings if you need detailed logs in Log Analytics.

  5. Subscribe to Azure Service Health alerts.
    Portal: Service Health > Health alerts.
    Select all services and regions you use. Select all event types.

Note

All of these monitoring tools have costs associated with the data they collect and store. Log Analytics charges for data ingestion and retention. Metric alerts are billed per-alert-rule-per-month. For a small subscription, these costs are minimal (usually a few dollars per month). For a large subscription with many resources, budget for monitoring costs as a line item — typically 5-10% of total infrastructure cost.

Common Monitoring Mistakes on New Subscriptions

  1. Not setting a budget alert before deploying anything. Budget alerts should be created before your first resource, not after the first bill shock. Cost Management needs a few days to process recent spending, so the sooner you set it up, the sooner it works reliably.
  2. Creating alerts but not testing them. An alert with a typo in the email address or a misconfigured action group silently fails to send notifications. After creating an alert, verify the action group by sending a test notification (available in the portal action group UI). Check your spam folder if you do not see it.
  3. Assuming the Activity Log covers everything. The Activity Log records management plane operations (create, modify, delete resources). It does not record data plane operations (reading or writing data to a storage account, executing a query in SQL). For data plane auditing, enable diagnostic settings and audit logs on the specific service.
  4. Not exporting the Activity Log before 90 days elapses. The default 90-day retention is enough for routine operations but not for security investigations, compliance audits, or incident postmortems. If you need historical log data, set up the Log Analytics export on day one.
  5. Setting alerts on every metric at default thresholds. Alert fatigue is real. If every minor CPU spike sends an email, teams start ignoring the alerts — including the important ones. Start with alerts only on the metrics that indicate genuine problems requiring action: sustained high CPU (not spikes), resource unavailability, and cost thresholds.

Related topics to read next

These pages build on the subscription management topics covered here.

Frequently asked questions

What is the difference between Azure Monitor and Azure Cost Management?

Azure Monitor collects operational data — metrics (CPU, memory, latency), logs (application logs, diagnostic data), and traces. It helps you understand whether your resources are running correctly. Azure Cost Management tracks financial data — what you are spending and on what. Both are essential, but they answer different questions: Monitor answers "is my system healthy?" and Cost Management answers "how much am I spending?"

How do I know if a cost alert is working before I actually spend money?

You can test a budget alert by setting the threshold to a very small amount (like $1) in a subscription you are actively using. If you see spending in Cost Management, the alert should trigger. Alternatively, review the alert in Cost Management under Budgets to confirm it shows "Enabled" status and has an email address configured. Azure sends a confirmation email when the alert is first created.

Can I set up all of this monitoring in the portal instead of the CLI?

Yes. Every step in this page can be done through the Azure portal. The CLI commands are provided because they are easier to document, repeat, and automate. If you are new to the CLI, follow the portal steps instead — the concepts and configurations are identical regardless of which interface you use.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.