Azure Logic Apps + Nodinite: Reduce Observability TCO

Azure Logic Apps can accumulate a surprisingly large amount of workflow execution data. For high-volume integrations, the combination of run history, diagnostic telemetry, Log Analytics, Application Insights, and Business Process Tracking (BPT) can mean that Azure stores and processes the same integration activity in several places at significant cost.

Nodinite takes a different approach: use the Logic Apps diagnostic stream as the signal, retrieve detailed execution information through the Logic Apps REST API, and use the same captured integration data for monitoring, long-term storage, correlation, and Business Process Management (BPM).

In short: Nodinite can lower your Azure costs when it replaces long Azure run-history retention and duplicate payload storage in Log Analytics and Application Insights. Your actual savings depend on your workload, payload sizes, retention requirements, hosting plan, Azure pricing agreement and region, network topology, and on the Nodinite license and SQL Server costs for the Log Databases, which the figures on this page don't include.

Understanding the Architecture Difference

Without Nodinite, the typical Azure architecture creates multiple separate data stores for the same integration activity:

Diagram: The run history in Azure Storage (yellow) is always on and is the store to reduce. Log Analytics, Application Insights, and Business Process Tracking (orange, dotted) are optional add-ons that each store and bill the same activity again.

• Run history in Azure Storage is mandatory. Every Logic App keeps it, with inputs and outputs, for the retention period. This is the store Azure administrators should reduce when Nodinite keeps the long-term history.
• Log Analytics, Application Insights, and Business Process Tracking are optional. Azure Monitor customers add them for logging, search, and business tracking. With Nodinite, you don't need any of them for Logic Apps logging, monitoring, or BPM.

With Nodinite, the integration-specific architecture becomes much simpler:

Diagram: The agent reads the events from the Event Hub (teal), applies the Logging filters (orange), and fetches payloads from the run history (yellow) only for the Actions that match. Nodinite (green) then uses the same dataset for monitoring, long-term storage, and BPM, so the run history only needs to cover the short window until the agent has fetched the payloads.

Tip

A good naming convention makes the Actions you want to log easy to find. Give them a common name, such as Send message - Logging, and add one Action filter that matches it. See Actions Tab (Filter Configuration Entry).

Example: Actions named with Logging match a single Action filter in the agent.

The key idea is use the integration data once, for many purposes.

The potential storage difference

Azure run history keeps every Action invocation of every run, with its inputs and outputs, for the whole retention period. That includes every iteration of every loop: a single run of a workflow that loops over a large batch can invoke Actions hundreds of thousands of times, and Azure stores all of them.

Nodinite doesn't have to keep everything Azure keeps. The Logging filters in the Logic Apps agent decide which events become Log Events before anything is stored:

• Action filters log only the Actions you name, for example the shapes named Logging that receive and send the business message
• Limit to 1st repetition (the default) logs only the first iteration inside loops, and Max Log Events caps the rest
• Payload settings per filter decide whether input and output bodies are kept at all
• Message Type retention then decides how long each kept Log Event stays, for example invoices for 7 years and test messages for 30 days

Consider a high-volume environment where Azure accumulates 18 TB of workflow run history:

                    AZURE RETAINED DATA
                         18 TB
              every Action, every repetition
                           │
                           │ Action filters
                           │ 1st repetition only
                           │ Message Type policies
                           ▼
                    ┌──────────────┐
                    │ What matters │
                    │ to the       │
                    │ integration  │
                    │ history      │
                    └──────┬───────┘
                           │
                           ▼
                         137 MB
                    NODINITE STORAGE

That is a 99.999% reduction in retained volume in this example. The reduction is that large because Azure keeps the internal steps and loop iterations of every run, while Nodinite keeps only the few business-relevant steps per run. Your own figure depends on how many Actions and repetitions your workflows run and on your filter settings: workflows with few Actions and no loops see a smaller difference. See Understanding Logic Apps logging filters for the settings.

Why this matters for your business

A typical Azure environment spreads the same activity over run history in Azure Storage, Log Analytics, Application Insights, and Business Process Tracking with its Azure Data Explorer (ADX) store (see the architecture diagram).

Nodinite brings the integration-specific concerns together around the same dataset:

• Monitoring Logic Apps — real-time health and alerting with Alarm Plugins
• Log Databases — long-term, cost-efficient storage
• BPM — business process visibility without additional Azure pipelines
• Log Views — role-based access for business and operations teams
• Search Fields — search by Order ID, Invoice Number, Customer ID across all history, extracted with Search Field Expressions
• Message Types — per-type retention policies (invoices 7 years, test messages 30 days)

Storage and cost model

The actual Azure cost depends heavily on the size and volume of the workflow data.

The examples below use:

• 15 activities per workflow run
• payload size means average combined input/output data per activity
• 90-day Azure run-history retention as the baseline, so about three months of data is stored at any time
• Consumption Logic Apps: the data retention list price of $0.12/GB per month (USD, pay-as-you-go). Standard Logic Apps store run history in your own storage account, billed at Azure Storage rates per GB and per transaction instead, so the $0.12 figures don't apply to Standard; use the Logic Apps Storage calculator for those
• figures cover run-history retention only; see Important pricing notes for what they leave out

Data volume generated

Payload size matters just as much as workflow volume. This is why Nodinite's selective Message Type-based retention is a meaningful design choice.

Illustrative Consumption retention cost at the 90-day default

Monthly cost once 90 days of run history has built up (three months of data at $0.12/GB per month):

Note

These numbers are an illustrative storage model for Consumption Logic Apps, not a prediction of an Azure invoice. Logic Apps billing includes other meters, and Standard Logic Apps are billed through their storage account instead.

Retention window comparison

For 1,000,000 Consumption runs/month with 15 activities/run at 100 KB/activity (approx. 1.43 TB/month):

If Nodinite provides the long-term integration history, customers can reduce Azure retention to the shortest period that still meets their operational troubleshooting requirements.

The diagnostic stream is smaller than you think

The Event Hub diagnostic stream is primarily the event transport and notification mechanism, not the payload store. Nodinite uses the Logic Apps REST API, with the access rights in Prerequisites, to retrieve detailed run and action information when required.

For an illustrative 100,000 workflow runs:

100,000 runs
     ×
~16 diagnostic events/run
     =
~1.6 million diagnostic events

At ~2 KB per event = ~3.2 GB
At ~5 KB per event = ~8 GB

The diagnostic stream is therefore much smaller than the underlying workflow payload volume; at these volumes it usually fits in a single Event Hub throughput unit. Event Hub retention, which sets how long the agent can be offline without losing events, is what more often drives the tier; see Configure Event Hubs. The cost advantage comes from letting Nodinite own the long-term store and leaving Azure responsible only for the short operational window.

The payloads Nodinite retrieves through the REST API still cross the network, and the ones it keeps are stored in your Log Databases. Include the network transfer, the SQL Server storage, and the Nodinite license when you compare total cost; see Azure Costs for Blob Storage and Event Hub for the Event Hub and network meters.

How to reduce Logic Apps run-history retention

Workflow retention is configured on the workflow, not on the diagnostic setting or Event Hub.

Important

Do not confuse Logic Apps run-history retention with diagnostic log retention. They are independent settings.

Consumption Logic Apps

1. Open the Logic App in the Azure portal.
2. Open the workflow in the Logic App designer.
3. Select Workflow settings.
4. Under Runtime options, find Run history retention in days.
5. Select Custom.
6. Set the retention period to the number of days you require.
7. Save the workflow.

Azure currently allows a minimum retention of 7 days and a maximum of 365 days.

Warning

For Consumption workflows, the same setting also limits how long a run may last. A run that takes longer than the retention period is removed from the run history, so keep the value above your longest-running workflow, for example one that waits for an approval.

Standard Logic Apps

For Standard Logic Apps, retention can be configured through the workflow runtime configuration. The default is also 90 days, with a minimum of 7 days. Configure the application setting:

Workflows.RuntimeConfiguration.RetentionInDays

For an individual workflow, Standard Logic Apps also supports:

Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays

A cleanup job removes old run history every 7 days by default, so data can be up to 7 days older than the retention setting. Set the host setting Runtime.FlowMaintenanceJob.RetentionCooldownInterval to a shorter interval if you need old data removed sooner.

Choosing the retention period

If Nodinite already provides long-term message storage, 7–14 days may be sufficient for many integration workloads. Base the value on operational and compliance requirements, not on the Azure default.

Diagnostic Settings and Event Hubs are separate

Azure Logic Apps can also send diagnostic data to destinations such as Log Analytics, Storage Accounts, or Event Hubs. These are separate from the workflow's own run-history retention.

Reducing Event Hub retention reduces the amount of diagnostic data kept in that Event Hub, but it does not reduce the Logic App's workflow run history. The two settings must be considered separately:

Diagram: Run-history retention (yellow) is set on the workflow. The diagnostic setting sends to the Event Hub (teal) that Nodinite reads. The other destinations (orange, dotted) are optional, and Nodinite doesn't need them.

Nodinite needs only two things from Azure: the Event Hub destination in the diagnostic setting, and a short run history to fetch payloads from. Log Analytics and Storage Account destinations, and Application Insights (which Standard Logic Apps enable through an app setting, not a diagnostic setting), are optional. Remove them, or keep them small, when Nodinite does the logging.

Azure Business Process Tracking vs. Nodinite BPM

Azure Business Process Tracking (BPT) for Standard Logic Apps stores tracking information in Azure Data Explorer.

Nodinite BPM addresses the same fundamental business need — understanding an integration as a business process — but with a key architectural advantage: BPMs in Nodinite are late bound, and any number of them can use the same Log Events.

Azure Business Process Tracking binds each business process to its workflow at design time, and tracks only what runs after it's deployed. In Nodinite, the binding of Log Events to BPM steps is resolved when the BPM is displayed. You pour the Log Events onto a BPM and see which steps they match, including events logged before the BPM existed.

Diagram: The same Log Events (green) feed a business BPM (blue), a much more detailed technical BPM (purple) that reuses the steps it shares with the business one, and any number of BPMs added later (teal).

For example, a business owner follows Order-to-Cash in seven steps across four Domains. A developer follows the same orders in a technical BPM with 50 steps across eight Domains. The steps they share show the same events, and the technical BPM adds the detail behind them. Neither BPM required a change to the Logic Apps or a new Azure tracking pipeline. See Multiple BPM Views on the Same Log Data and No Upfront Binding to Workflows.

Recommended Nodinite architecture

When Nodinite is used for long-term storage, consider keeping the Azure-native run history only for the period needed for operational troubleshooting. Azure can still be used for what it does best — infrastructure and platform observability — while Nodinite becomes the integration-specific system of record.

Responsibilities

Azure Logic Apps

• Short-term execution history and troubleshooting (7–14 days), with the View Run History Remote Action in Nodinite for the same window

Nodinite

• Everything listed in Why this matters for your business, with access granted per Role in Log Views and Monitor Views

The strongest TCO argument is not simply that Nodinite is cheaper than Azure. It is that Nodinite consolidates integration monitoring, long-term storage, correlation, and BPM around the same integration dataset, while allowing customers to keep Azure workflow history as a short operational window and selectively retain only the integration data that matters.

Apply the same approach to your other Azure services

If you use Nodinite for Logic Apps, you likely log other Azure services the same way. The cost argument is the same everywhere: store payloads once, in Nodinite, and keep Azure retention short.

In every case, the logged data is also available to the business through role-based Log Views, across all these services in one place. Read why that matters in Built for developers and the business.

Important pricing notes

The figures in this document are illustrative calculations, not Azure price quotes. Actual costs depend on:

• Azure region, pricing agreement, and Consumption versus Standard tier
• execution volume, payload sizes, and number and type of actions per run
• storage operations and diagnostic categories enabled
• Log Analytics, Application Insights, and ADX/BPT configuration
• Event Hub configuration and throughput
• network topology, private endpoints, and data transfer (evaluate these separately)
• the Nodinite license and the SQL Server storage for the Log Databases

Microsoft references

• Logic Apps limits and configuration
• Logic Apps pricing
• Manage costs for Azure Logic Apps
• View workflow status and run history
• Collect diagnostic data for workflows
• Configure Standard Logic Apps application and host settings
• Azure Monitor Logs cost and usage
• Azure Business Process Tracking overview
• Azure Event Hubs pricing

Next Steps

Prerequisites for Azure Logic Apps Logging and Monitoring Agent
About Logic Apps Logging Options
Configure Logging filters — choose which Actions and payloads to keep
Configure Message Types — define per-type retention policies

Related Topics

• Logic Apps Logging and Monitoring Overview
• Log Databases — long-term, cost-efficient storage
• Message Types — per-type retention control
• Search Fields — search by business identifiers
• Log Views — role-based access to integration history
• BPM — cross-platform business process visibility
• Why Nodinite BPM is superior to Azure Business Process Tracking
• Monitoring Logic Apps
• Logging Logic Apps
• Managing Logic Apps
• ARM Template
• Troubleshooting
• Configure Event Hubs
• Azure Costs for Blob Storage and Event Hub — Event Hub and Blob Storage costs in the logging pipeline
• Reduce Azure API Management Logging Costs — the same approach for API Management
• Reduce Azure Functions Logging Costs — the same approach for Azure Functions