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).
Understanding the Architecture Difference
Without Nodinite, the typical Azure architecture creates multiple separate data stores for the same integration activity:
AZURE LOGIC APPS
│
┌────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Run History Diagnostics BPT
│ │ │
▼ ▼ ▼
Azure Storage Log Analytics ADX
│
Application Insights
│ │ │
└────────────────┴─────────────────┘
Multiple stores
Multiple costs
With Nodinite, the integration-specific architecture becomes much simpler:
AZURE LOGIC APPS
│
│ Diagnostic setting
▼
Event Hub
│
▼
NODINITE
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
Monitoring Long-term BPM
Storage Correlation
│ │ │
└────────────┴────────────┘
SAME DATASET
The key idea is use the integration data once, for many purposes.
The potential storage difference
Consider a high-volume environment where Azure accumulates 18 TB of workflow data.
Nodinite does not have to retain everything that Azure retained. Nodinite can apply Message Type filters and retention policies before data is committed to its long-term storage:
AZURE RETAINED DATA
18 TB
│
│ Nodinite filtering
│ Message Type policies
│ Business relevance
▼
┌──────────────┐
│ What matters │
│ to the │
│ integration │
│ history │
└──────┬───────┘
│
▼
137 MB
NODINITE STORAGE
That is a 99.999% reduction in retained volume in this illustrative example. The important point is not the specific figure — it is that Nodinite retention is policy-driven and selective, rather than requiring everything retained by Azure to become long-term integration storage.
Why this matters for your business
A typical Azure environment may use:
- Logic Apps run history for execution details and payloads
- Log Analytics for diagnostic telemetry
- Application Insights for application/workflow telemetry
- Business Process Tracking for business-process transactions
- Azure Data Explorer (ADX) for BPT data
- Azure Storage as part of the underlying Logic Apps runtime
Nodinite brings the integration-specific concerns together around the same dataset:
- Monitoring Logic Apps — real-time health and alerting
- 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
- 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
- figures are illustrative storage calculations, not Azure price quotes
Data volume generated
| Workflow runs/month | 10 KB/activity | 50 KB/activity | 100 KB/activity | 500 KB/activity |
|---|---|---|---|---|
| 100,000 | ~14 GB | ~72 GB | ~143 GB | ~715 GB |
| 1,000,000 | ~143 GB | ~715 GB | ~1.43 TB | ~7.15 TB |
| 10,000,000 | ~1.43 TB | ~7.15 TB | ~14.3 TB | ~71.5 TB |
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 retention cost at $0.12/GB-month
| Workflow runs/month | 10 KB/activity | 50 KB/activity | 100 KB/activity | 500 KB/activity |
|---|---|---|---|---|
| 100,000 | ~$1.72/mo | ~$8.58/mo | ~$17.16/mo | ~$85.80/mo |
| 1,000,000 | ~$17.16/mo | ~$85.80/mo | ~$171.60/mo | ~$858/mo |
| 10,000,000 | ~$171.60/mo | ~$858/mo | ~$1,716/mo | ~$8,580/mo |
Note
These numbers are an illustrative storage model, not a prediction of an Azure invoice. Logic Apps billing includes additional storage operations and other meters.
Retention window comparison
For 1,000,000 runs/month with 15 activities/run at 100 KB/activity (approx. 1.43 TB/month):
| Azure retention | Approx. retained payload | Illustrative storage cost |
|---|---|---|
| 7 days | ~334 GB | ~$40/month |
| 14 days | ~668 GB | ~$80/month |
| 30 days | ~1.43 TB | ~$172/month |
| 90 days (default) | ~4.29 TB | ~$515/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 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. The cost advantage comes from letting Nodinite own the long-term store and leaving Azure responsible only for the short operational window.
How to reduce Logic Apps run-history retention
The setting 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
- Open the Logic App in the Azure portal.
- Open the workflow in the Logic App designer.
- Select Workflow settings.
- Under Runtime options, find Run history retention in days.
- Select Custom.
- Set the retention period to the number of days you require.
- Save the workflow.
Azure currently allows a minimum retention of 7 days and a maximum of 365 days.
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
Choosing the retention period
| Retention | Typical purpose |
|---|---|
| 7 days | Minimal Azure troubleshooting window |
| 14 days | Short operational investigation window |
| 30 days | Longer operational support window |
| 90 days | Azure default |
| 365 days | Extended Azure-native run history |
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:
Logic App
│
├── Workflow Run History
│ └── Configure: Run history retention in days
│
└── Diagnostic Settings
│
├── Log Analytics
├── Storage Account
└── Event Hub
└── Separate diagnostic retention
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: Nodinite BPM can use the same already-collected integration data for multiple BPM definitions.
SAME NODINITE DATA
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Order Process Invoice Process Shipment Process
Adding another BPM perspective does not require changing the Logic App or creating another Azure tracking pipeline. The data is already available to Nodinite.
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)
Nodinite
- Long-term integration history
- Message Type-based retention (invoices 7 years, test messages 30 days)
- Search Fields — search by Order ID, Customer ID, Invoice Number across all history
- Log Views — role-based access for business teams without Azure Portal credentials
- BPM — cross-platform business process visibility using data already collected
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.
Important pricing notes
The figures in this document are illustrative calculations, not Azure price quotes. Actual costs depend on:
- Azure region and customer pricing agreement
- Logic Apps Consumption versus Standard tier
- workflow execution volume and payload sizes
- number and type of actions per run
- storage operations and diagnostic categories enabled
- Log Analytics ingestion and retention configuration
- Event Hub configuration and throughput
- Application Insights and ADX/BPT configuration
- network topology and private endpoints
- data transfer between regions and services
Network and access costs should be evaluated separately from storage and ingestion costs.
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 Step
Prerequisites for Azure Logic Apps Logging and Monitoring Agent About Logic Apps Logging Options 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
- Monitoring Logic Apps