Skip to article
Analytics Streaming analytics

Stream Analytics output

A Stream Analytics output is where processed events go after the query runs. It might be a storage account, SQL table, Event Hubs stream, Cosmos DB container, Azure Data Explorer table, Power BI dataset, Azure Function, or another supported sink. The output name is used in the query, so a small naming or schema mistake can send results nowhere useful. For operators, outputs are the handoff point between real-time processing and the systems people actually read, alert from, or store.

Source: Microsoft Learn - Azure Stream Analytics output types overview Reviewed 2026-05-26T18:37:22Z

Exam trap
Changing an output alias without updating the query INTO clause that references it.
Production check
List outputs and confirm every alias appears exactly in the transformation query.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Stream Analytics output, ASA output, Stream Analytics sink, output sink, query output destination
Difficulty
fundamentals
CLI mappings
4
Last verified
2026-05-26T18:37:22Z
Review level
field-manual-complete
Article depth
field-manual-complete
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

Stream Analytics output matters because the best query is worthless if results cannot land reliably in the right destination. Outputs determine whether a stream becomes an alert, dashboard, archive, database row, downstream event, or automation trigger. Schema mismatch, missing permissions, throttled sinks, bad partitioning, or wrong aliases can make a healthy job look broken. Output design also affects replay strategy: restarting a job can duplicate writes if the destination is not idempotent. Strong teams review output contracts, destination capacity, authentication, error policy, and monitoring before production because this is where live events become durable business facts. for downstream teams consistently.

Official wording and source

A Stream Analytics output is a named destination that receives results from a job’s query. A job can write to one or multiple output types, and the query references each output by name using the INTO clause so transformed events land in the intended sink.

Open Microsoft Learn

Technical context

In Azure architecture, a Stream Analytics output is a data-plane connection from the job to a destination service. It includes the output alias, destination type, authentication method, serialization, partitioning options, schema assumptions, and sometimes path or table settings. Query statements use INTO to send records to that alias. Outputs interact with managed identity, connection strings, firewall posture, target throughput, diagnostics, and output error policy. They are configured through the portal, CLI, PowerShell, REST, templates, Visual Studio Code, or no-code editor depending on the scenario.

Exam context

Compare with

Stream Analytics input Output binding Event Hubs capture Service Bus queue

Where it is used

Where you see it

  1. In the Stream Analytics job Outputs blade, each configured alias shows its destination type, authentication details, serialization, partitioning or path settings, and test connection status.
  2. In a Stream Analytics query, output aliases appear after INTO, telling the job which configured sink should receive each SELECT statement’s result stream. by alias.
  3. In diagnostic logs and metrics, output failures, serialization errors, throttling, and destination write problems appear when the job produces events but the sink cannot accept them.

Common situations

  • Write filtered IoT alerts to Service Bus or Event Hubs so another operational system can act immediately.
  • Land aggregated events in Azure SQL or Cosmos DB when applications need queryable real-time facts.
  • Archive processed records to Blob Storage or Data Lake Storage Gen2 for audit, replay, or batch analytics.
  • Feed Azure Data Explorer or Power BI dashboards with near-real-time operational metrics.
  • Split one query into multiple outputs so urgent alerts, durable archives, and analytics stores receive different result shapes.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Insurer fixes telematics SQL output failures An auto insurer used Stream Analytics to process driver telematics, but discount calculations stopped updating after a schema change. The job was running, yet SQL output failures filled support queues.
Scenario

An auto insurer used Stream Analytics to process driver telematics, but discount calculations stopped updating after a schema change. The job was running, yet SQL output failures filled support queues.

Goals
  • Restore trusted writes to the discount-scoring table before monthly billing.
  • Separate query logic problems from destination schema problems.
  • Prevent replay from creating duplicate score records.
Approach using Stream Analytics output

Engineers listed and showed the Stream Analytics output definition, then compared the SQL table schema with the fields emitted by the query. The output alias was correct, but a newly added riskBand field had no matching target column. The team updated the SQL schema, changed the output error policy review checklist, and added deterministic driver-period keys for replay protection. Diagnostic logs and SQL metrics were placed side by side in the runbook so future incidents could prove whether the query or destination failed.

Potential outcomes
  • Billing-risk score updates resumed within 45 minutes of root cause confirmation.
  • Duplicate score rows during replay dropped to zero in the next monthly cycle.
  • Support tickets about missing discounts fell by 63 percent after the checklist change.
  • The team avoided rewriting the query because CLI and logs proved the sink schema was the failure point.
What to learn

A Stream Analytics output is a contract with the destination, not just a place to send rows.

Scenario 02 Sports analytics provider splits live stats to two sinks A sports analytics provider delivered live match statistics to broadcasters and internal analysts. One shared output caused dashboard delays whenever archival ingestion grew during tournament weekends.
Scenario

A sports analytics provider delivered live match statistics to broadcasters and internal analysts. One shared output caused dashboard delays whenever archival ingestion grew during tournament weekends.

Goals
  • Separate broadcaster alerts from long-term analytics storage.
  • Keep live-stat latency under five seconds for premium feeds.
  • Preserve full event history for post-match model training.
Approach using Stream Analytics output

The team redesigned Stream Analytics outputs so one SELECT statement wrote compact live alerts to Event Hubs and another wrote enriched statistics to Azure Data Explorer. CLI output listings confirmed the aliases used by each INTO clause, and destination metrics were added to the release gate. The job kept the same inputs but produced two result shapes, allowing the broadcaster path to stay lean while the analytics path stored richer records for later analysis. Broadcasters received the lean path through a separately monitored namespace. A pregame replay validated both destination paths.

Potential outcomes
  • Premium feed latency improved from 18 seconds to under four seconds during weekend peaks.
  • Archive completeness reached 99.8 percent without slowing live alert delivery.
  • Broadcaster escalation calls dropped from seven in the prior tournament to one.
  • Destination-specific monitoring showed Event Hubs pressure separately from Azure Data Explorer ingestion.
What to learn

Multiple outputs let one streaming query serve different business needs without forcing every sink to carry the same load.

Scenario 03 Pharmaceutical lab creates replay-safe audit archive A pharmaceutical research lab streamed equipment readings from stability chambers. Auditors needed durable evidence, while scientists needed quick anomaly notifications, and the old single database output was overloaded.
Scenario

A pharmaceutical research lab streamed equipment readings from stability chambers. Auditors needed durable evidence, while scientists needed quick anomaly notifications, and the old single database output was overloaded.

Goals
  • Archive processed chamber readings in a durable, queryable storage path.
  • Notify scientists quickly when readings crossed approved thresholds.
  • Reduce database pressure without losing audit traceability.
Approach using Stream Analytics output

The lab configured Stream Analytics outputs for separate duties: Blob Storage with date-based paths for audit archives, Service Bus for anomaly workflow, and Azure SQL only for summarized active-batch status. The query used distinct INTO clauses for each output. Operators reviewed path naming, output aliases, retention, and managed identity access before validation. Replay procedures documented which outputs were idempotent and which needed duplicate checks, preventing an audit archive from being confused with a workflow trigger. Validation runs compared archive counts with source batches before release.

Potential outcomes
  • SQL write volume dropped by 54 percent while archive completeness stayed above 99.9 percent.
  • Scientists received threshold notifications within 70 seconds instead of checking periodic reports.
  • Audit packet preparation fell from three days to half a day using organized archive paths.
  • Replay drills completed without duplicate workflow tickets because output behavior was documented.
What to learn

Choosing the right output shape can protect performance, auditability, and human workflows at the same time.

Azure CLI

After years of Azure incident work, I use CLI for outputs because output problems are easy to misread from the portal. CLI lets me list all outputs on a job, show exact datasource properties, test connectivity where supported, capture JSON for change records, and compare aliases between environments. It also helps during a failed deployment when the query references an output name that does not exist or points to the wrong table, hub, or container. Portal screens are fine for one destination; CLI is better when you need evidence, automation, drift detection, and repeatable checks across many jobs. during incidents.

Useful for

  • List all outputs under a job and confirm aliases match every INTO clause in the query.
  • Show an output definition to inspect destination type, datasource settings, serialization, and authentication method.
  • Test output connectivity where supported before starting a job or approving a sink migration.
  • Export output JSON from multiple environments to detect drift in table, container, hub, or path configuration.
  • Update or remove an output only after checking downstream consumers, replay behavior, and output error policy.

Before you run a command

  • Confirm tenant, subscription, resource group, job name, output name, and destination service before inspecting or changing an output.
  • Know whether the command is read-only or mutating because changing an output can break live dashboards, archives, or alerts.
  • Check destination permissions, schema, firewall rules, partitioning, and cost impact before running test, update, or create commands.
  • Use JSON output for evidence when comparing dev, test, and production output definitions.

What the output tells you

  • Output list shows the aliases available to INTO clauses and helps catch missing or unexpectedly named destinations.
  • Datasource properties reveal the actual SQL, Event Hubs, Storage, Data Lake, Cosmos DB, Power BI, or Azure Data Explorer target.
  • Serialization and partition fields explain how records are shaped, grouped, and written at the destination.
  • Test or error output helps separate destination connectivity and schema problems from query or input problems.

Mapped commands

Stream Analytics output inventory and validation

validates 
az stream-analytics output list --job-name <job-name> --resource-group <resource-group> --output table
az stream-analytics outputdiscoverAnalytics
read-only Microsoft Learn 
az stream-analytics output show --job-name <job-name> --resource-group <resource-group> --name <output-name>
az stream-analytics outputdiscoverAnalytics
read-only Microsoft Learn 
az stream-analytics output test --job-name <job-name> --resource-group <resource-group> --name <output-name>
az stream-analytics outputdiscoverAnalytics
read-only Microsoft Learn 
az stream-analytics output delete --job-name <job-name> --resource-group <resource-group> --name <output-name>
az stream-analytics outputremoveAnalytics
destructive Microsoft Learn

Architecture context

A Stream Analytics output is the downstream contract for the streaming application. Architects must decide whether results should become hot operational alerts, durable archives, dashboard records, database facts, or new events for another processor. Each destination has different behavior: SQL needs matching table schema, Event Hubs favors event fan-out, Data Lake supports archival paths, Azure Data Explorer handles telemetry analytics, Cosmos DB needs partitioning, and Power BI supports near-real-time visualization. The output contract should document alias, destination, authentication, schema, partition key, retry expectations, idempotency, retention, monitoring, and owner. Without that contract, query changes can silently break downstream consumers. every time.

Security
Security impact is direct because an output grants the job write access to another system. That destination may hold trusted operational records, customer analytics, finance events, or alerts that trigger action. Use managed identity where supported, keep keys and connection strings out of code, scope permissions to the target table, container, hub, or database, and restrict network exposure according to the sink’s capabilities. Output names and destinations should be reviewed in change control because a wrong sink can leak data or corrupt records. Logs should capture output failures without exposing sensitive payloads unnecessarily. during compliance reviews and audits consistently.
Cost
Outputs influence cost by controlling how many records leave the job and where they land. A query that writes raw and aggregated events to multiple sinks can multiply storage, database RU, ingestion, dashboard, and logging costs. Partitioned storage paths may keep archives cheaper, while SQL, Cosmos DB, Power BI, or Azure Data Explorer can need extra capacity when event volume grows. Failed outputs also cost money through retries, incident labor, and replay. FinOps reviews should check output fan-out, row volume, destination SKU, retention, diagnostic logs, and whether abandoned outputs still receive data. across environments and teams with accountable owners clearly.
Reliability
Reliability depends heavily on the output sink. A Stream Analytics job can read and process events correctly but still fail because SQL rejects a schema, Event Hubs throttles, a storage path is wrong, or credentials expired. Output error policy controls whether invalid output events are dropped or cause failures, so it must match business tolerance. Operators should monitor output errors, late events, write latency, destination health, and retry behavior. For high-value pipelines, design idempotent writes, replay-safe destinations, and clear rollback procedures. Otherwise a restart may create duplicates or leave silent gaps. Operators should test destination failures before launch under load.
Performance
Output performance determines whether a job can keep up after processing events. Even a well-tuned query will back up when the destination cannot accept writes fast enough. SQL schema mismatch, Cosmos DB partition pressure, Event Hubs throughput, storage path design, Power BI limits, and Azure Data Explorer ingestion behavior all matter. Operators should compare output errors, write latency, SU utilization, watermark delay, and destination metrics before scaling the job. Partitioning and batching choices can improve throughput, but they must match the sink. The output is often where real-time latency goals are won or lost. during bursty production periods under load.
Operations
Operators inspect outputs before query releases, destination migrations, incident response, and replay. They list configured outputs, confirm each alias appears in the query, show datasource details, test connectivity where possible, and compare destination settings across environments. During incidents, output checks answer whether results are missing because the query produced none, the sink rejected them, or permissions changed. Common operational work includes rotating credentials, moving to managed identity, updating schemas, changing partition paths, enabling diagnostics, and documenting output owners. Good runbooks include both Stream Analytics job state and downstream service health. and clear escalation paths for destination owners during production incidents.

Common mistakes

  • Changing an output alias without updating the query INTO clause that references it.
  • Writing to SQL, Cosmos DB, or Azure Data Explorer before confirming target schema, partition key, and throughput.
  • Assuming every output is idempotent during replay and then creating duplicate downstream records.
  • Using embedded keys or broad permissions when managed identity and scoped access are supported.
  • Scaling the Stream Analytics job when the real bottleneck is output throttling or destination rejection.