Manual throughput - Azure Glossary

Microsoft Learn

Manual throughput is a Cosmos DB throughput mode where teams set a fixed RU/s value instead of using autoscale. Teams use it when a database or container has predictable traffic and operators want explicit request-unit capacity. In plain English, it gives operators a named control for controlled RU/s spending, predictable capacity, and simpler throughput evidence for steady workloads instead of leaving the decision hidden in a portal setting, script, or deployment file. Treat it as production-ready only when the owner, dependencies, permission boundary, monitoring signal, and rollback evidence are clear.

Microsoft Learn: Introduction to provisioned throughput in Azure Cosmos DB2026-05-16T04:45:26Z

Technical context

Technically, manual throughput sits in the Cosmos DB request-unit capacity and database or container configuration layer. Azure represents it through manual throughput settings on a database or container, measured in provisioned RU/s. It usually interacts with Cosmos DB accounts, databases, containers, partition keys, physical partitions, autoscale choices, metrics, and alerts. The key boundary is that manual throughput fixes capacity until changed, so sudden traffic spikes can cause throttling. Architects should document scope, identity path, network assumptions, deployment method, monitoring hooks, and fallback behavior before production use.

Why it matters

Manual throughput matters because it makes controlled RU/s spending, predictable capacity, and simpler throughput evidence for steady workloads visible, testable, and owned. Without that clarity, teams can change the wrong scope, miss hidden dependencies, or troubleshoot symptoms caused by configuration drift rather than application code. It also gives reviewers a common language for security, reliability, operations, cost, and performance decisions. A good implementation states who owns the setting, what workload depends on it, how changes are approved, and which metric or log proves the result. That keeps audits, migrations, incidents, and release reviews from becoming guesswork. Keep the decision visible in runbooks, diagrams, tags, and support notes.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In the Azure portal, manual throughput appears in configuration, monitoring, or access views where teams verify ownership, dependencies, permissions, readiness, and rollback evidence before changes.

Signal 02

In CLI, IaC, or query output, manual throughput appears as properties, status, scope, and dependency evidence that operators compare with the approved design during reviews.

Signal 03

In architecture reviews, manual throughput appears when teams discuss ownership, access, reliability, cost, performance, and evidence needed to prove the design is safe during reviews.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

Use Manual throughput to make ownership, configuration evidence, monitoring, and rollback behavior explicit.
Review Manual throughput during design reviews, release readiness checks, incident response, and post-change validation.
Document Manual throughput with related identities, network paths, policies, cost drivers, and operational runbooks.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Predictable billing workload capacity

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

SaaSWorks Ledger, a business software organization, served a steady stream of tenant billing records and wanted predictable Cosmos DB spend rather than autoscale variability. The team used manual throughput to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.

Business/Technical Objectives

Keep monthly database cost within 5% of forecast.
Avoid throttling during normal invoice runs.
Document RU/s ownership for FinOps.
Reduce emergency throughput changes.

Solution Using Manual throughput

The team measured request-unit consumption for thirty days and found predictable invoice write patterns. They configured manual throughput at the container level, leaving enough headroom for daily invoice peaks while avoiding autoscale maximum charges. Azure Monitor alerts watched normalized RU consumption and throttled requests. CLI checks captured throughput, partition key, and container settings before finance approved the new cost model. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability.

Results & Business Impact

Monthly Cosmos DB cost stayed within 3% of forecast.
Throttled requests dropped below 0.2% during invoice runs.
Emergency throughput updates fell 64%.
FinOps reports linked RU/s ownership to the billing platform team.

Key Takeaway for Glossary Readers

Manual throughput works well when Cosmos DB traffic is predictable and teams want stable reserved capacity.

Case study 02

Fixed capacity for market reference data

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

EastBank Markets, a financial trading organization, needed fixed capacity for a trade-reference container that received consistent traffic during market hours. The team used manual throughput to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.

Business/Technical Objectives

Maintain P99 reads under 15 milliseconds.
Reserve capacity for market-hour traffic.
Avoid cost spikes from autoscale maximums.
Prove partition design before approval.

Solution Using Manual throughput

Database engineers analyzed RU consumption by partition key and query type, then assigned manual throughput to the reference-data container. They tuned indexing policy to reduce read cost and configured alerts for throttling and hot partitions. CLI output documented the configured RU/s and container partition key. Because usage was stable, the team scheduled quarterly capacity reviews instead of reacting to every short-term utilization change. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability.

Results & Business Impact

P99 read latency averaged 11 milliseconds.
Autoscale cost spikes were avoided.
Quarterly reviews replaced weekly emergency tuning.
Hot partition alerts caught one malformed client query.

Key Takeaway for Glossary Readers

Manual throughput can support latency-sensitive Cosmos DB workloads when traffic shape and partition design are well understood.

Case study 03

Dispatch planning throughput right-sizing

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

RouteSpring Logistics, a transportation logistics organization, had dispatch-planning containers that ran predictable planning jobs every hour and wasted money on high autoscale ceilings. The team used manual throughput to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.

Business/Technical Objectives

Lower Cosmos DB spend by 20%.
Keep hourly planning jobs under ten minutes.
Reduce throttling during route recalculation.
Create a repeatable capacity review process.

Solution Using Manual throughput

Operators compared autoscale consumption history with job run times and found that manual throughput at the database level could serve all planning containers. They moved capacity to shared database throughput, validated partition-key distribution, and set alerts for normalized RU consumption. CLI output was stored with the change record, and the runbook explained when to raise RU/s temporarily for holiday traffic. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability. After release, the platform team reviewed metrics weekly and kept the implementation aligned with security, reliability, and cost expectations.

Results & Business Impact

Cosmos DB spend fell 24%.
Hourly planning jobs averaged seven minutes.
Throttling incidents dropped 31%.
Capacity reviews became part of seasonal readiness.

Key Takeaway for Glossary Readers

Manual throughput can reduce cost when multiple stable containers share a predictable request-unit budget.

Why use Azure CLI for this?

Azure CLI is useful for manual throughput because it turns the live configuration into repeatable evidence. Operators can inventory scope, compare settings with IaC, confirm identity and network assumptions, and export facts for change reviews or incidents without relying on screenshots.

CLI use cases

Inventory Manual throughput settings across subscriptions or resource groups before reviews, migrations, and ownership cleanup.
Inspect live Manual throughput configuration before a release, audit, incident, rollback, or support handoff.
Export Manual throughput evidence so teams can compare portal state, IaC intent, activity logs, and monitoring results.

Before you run CLI

Confirm tenant, subscription, resource group, scope, and service-specific permissions before inspecting or changing Manual throughput.
Know whether the command is read-only or changes production behavior, cost, routing, identity, or network exposure.
Choose JSON, table, or TSV output deliberately so the result can be reviewed, scripted, or attached to evidence.

What output tells you

The output shows whether manual throughput exists, where it is scoped, and which resource or workload currently owns it.
Status, identity, network, SKU, policy, metric, or dependency fields reveal whether live configuration matches the intended design.
Repeated output over time can prove drift, confirm remediation, or show that a change reached the correct Azure resource.

Mapped Azure CLI commands

Manual throughput Azure CLI checks

az cosmosdb sql container throughput show --account-name <account> --database-name <database> --name <container> --resource-group <group>

az cosmosdb sql container throughputdiscoverDatabases

az cosmosdb sql container throughput update --account-name <account> --database-name <database> --name <container> --resource-group <group> --throughput <ru>

az cosmosdb sql container throughputconfigureDatabases

az cosmosdb sql database throughput show --account-name <account> --name <database> --resource-group <group>

az cosmosdb sql database throughputdiscoverDatabases

az cosmosdb sql container show --account-name <account> --database-name <database> --name <container> --resource-group <group>

az cosmosdb sql containerdiscoverDatabases

Architecture context

Technically, manual throughput sits in the Cosmos DB request-unit capacity and database or container configuration layer. Azure represents it through manual throughput settings on a database or container, measured in provisioned RU/s. It usually interacts with Cosmos DB accounts, databases, containers, partition keys, physical partitions, autoscale choices, metrics, and alerts. The key boundary is that manual throughput fixes capacity until changed, so sudden traffic spikes can cause throttling. Architects should document scope, identity path, network assumptions, deployment method, monitoring hooks, and fallback behavior before production use.

Security

Security for Manual throughput starts with least privilege and clear ownership. The main risk is giving teams broad rights to change throughput without approval, cost ownership, or workload-impact review. Review who can create, update, delete, assign, invoke, or read it, and whether access comes from direct roles, inherited roles, managed identities, secrets, or deployment pipelines. Prefer managed identity, scoped RBAC, private access, encryption, and logged approvals when the service supports them. For production, keep evidence of permission scope, network exposure, diagnostic logging, and rollback authority so a security review can verify live state rather than trusting documentation alone. Keep the decision visible in runbooks, diagrams, tags, and support notes.

Cost

Cost for Manual throughput is driven by provisioned RU/s, minimum throughput, container count, database sharing, and unused capacity during quiet periods. The spend may be direct, such as SKU, capacity, storage, throughput, replicas, retention, or network transfer, or indirect through support time and failed changes. FinOps reviews should identify the owner, billing tag, usage metric, and cheaper configuration that still meets the workload requirement. Do not reduce cost by weakening security, durability, compliance, or recovery needs without written approval. Track changes over time so teams can distinguish intentional scaling from forgotten resources, stale test deployments, and inefficient defaults. Keep the decision visible in runbooks, diagrams, tags, and support notes.

Reliability

Reliability for manual throughput depends on RU/s availability, 429 throttling rate, partition distribution, workload predictability, and alert coverage. Operators should know what happens during deployment, scale changes, failover, maintenance, dependency loss, and operator error. Some effects are direct, such as availability, recovery, throughput, or dead-letter behavior; others are indirect because the setting makes drift easier to detect and reverse. Document region assumptions, backups, health probes, retry behavior, dependency limits, and rollback steps. A reliable implementation lets support teams prove current state quickly before making emergency changes. Keep the decision visible in runbooks, diagrams, tags, and support notes. Review the evidence again after deployment so drift is caught early.

Performance

Performance for manual throughput depends on request latency, 429 responses, normalized RU consumption, partition hot spots, and query RU cost. The effect may appear as latency, throughput, IOPS, connection wait time, replica behavior, query duration, pipeline runtime, or faster operational troubleshooting. Measure before and after important changes instead of assuming the setting helps. Useful evidence includes metrics, logs, traces, activity records, deployment output, load-test results, and user-impact signals. When performance is indirect, state that clearly and focus on how the term improves diagnosis speed, configuration consistency, or workload routing. Keep the decision visible in runbooks, diagrams, tags, and support notes.

Operations

Operationally, manual throughput needs a repeatable inspection path. Teams should know which portal blade, CLI command, Resource Graph query, metric, activity log, workbook, or deployment artifact shows the live state. Runbooks should describe normal ownership, approved change windows, escalation contacts, rollback steps, and evidence to capture after changes. Avoid undocumented portal-only edits in production. Use IaC, tags, CLI exports, and monitoring so operators can compare actual configuration with the intended design during releases, incidents, and audits. Keep the decision visible in runbooks, diagrams, tags, and support notes. Review the evidence again after deployment so drift is caught early. Tie every change to an owner, monitoring signal, and rollback path.

Common mistakes

Changing manual throughput without checking dependent resources, owner tags, alerts, permissions, and rollback steps first.
Assuming the portal label is complete instead of validating live state through CLI, IaC, metrics, or activity logs.
Granting broad permissions for convenience, then forgetting to remove temporary access after troubleshooting or deployment.