How to Calculate Monthly IoT Data Usage for Devices and Fleets

A device may send only a few kilobytes of information at a time, but that doesn't tell you how much cellular data it will use in a month. Background communication, software updates, and daily activity all affect consumption. Here's how to estimate usage for individual IoT devices and larger deployments before choosing a data plan.

Table of Contents

1. Why Estimating IoT Data Usage Is More Complicated Than It Looks
2. Identify What Generates Data on Each Device
3. Calculate Baseline Data Usage From Reporting Frequency and Message Size
4. Account for Background Traffic and Network Overhead
5. Allow for Retries and Reconnection Traffic
6. Estimate Data Usage for a Connected Vending Machine
7. Plan for Software Updates and High-Usage Months
8. How Data Usage Estimates Change Across IoT Industries
9. Calculate Monthly Data Usage for an Entire IoT Fleet
10. Choose a Data Allowance and Build in a Reasonable Buffer
11. Validate Your Estimate Before Scaling the Deployment
12. Turn Your Data Estimate Into a Cellular Connectivity Plan

1. Why Estimating IoT Data Usage Is More Complicated Than It Looks

A company preparing to deploy 500 connected devices needs to decide how much cellular data each one will require. The hardware has already been selected, the application is ready, and the reporting frequency is known.

Someone takes the size of a typical message, multiplies it by the number of times the device reports each day, and calculates a monthly total. It seems reasonable, especially when the device sends only small amounts of information.

The problem is that the calculation covers only the traffic someone thought to count.

Consider a connected vending machine. Sales records and inventory updates are easy to identify because they are part of what the machine was designed to report. But the payment terminal may also communicate with its processor, the controller exchanges messages with a management platform, and certain background services remain active even when the machine has not made a sale for hours.

A software update adds another type of traffic. So does a remote configuration change, although the amount involved may be much smaller.

There is also a difference between the information an application sends and the data transferred over the cellular connection. A message can produce a response from the server, and the exchange itself requires additional network traffic. Both uploaded and downloaded data generally contribute to cellular consumption.

These differences are easy to overlook when planning a small deployment. They become harder to ignore when hundreds of devices are running every day.

A device using an additional 5 MB per month would add 2.5 GB to the monthly consumption of a 500-device fleet. That may or may not be financially significant under the selected plan, but it is worth knowing before the connections are activated.

Nobody needs to predict every kilobyte in advance. A useful estimate should be close enough to support a sensible data allowance, with a clear understanding of which activities could make actual usage higher.

2. Identify What Generates Data on Each Device

For some equipment, the list of connected functions is short. A sensor wakes up, sends a reading, and waits for the next reporting interval.

A vending machine can be less straightforward. Its payment terminal, telemetry controller, and optional advertising display may all communicate with different remote services. In some installations, they share a cellular connection. In others, the payment equipment has a separate modem.

That distinction matters before any calculations begin. Data carried over another connection should not be included in the allowance for the SIM being planned.

For a device with several connected functions, it is worth listing the applications and services using the cellular connection, including those that run without user interaction.

The categories are not completely independent. A transaction exchange may already include its server response and some protocol overhead. If that traffic has been measured at the cellular interface, adding another allowance for the same bytes would inflate the result.

It is also worth checking whether the cellular connection is used continuously.

For example, a device with wired internet and cellular backup may transfer very little application traffic over cellular while the primary connection is working. Its monthly usage will depend partly on how often the backup becomes active and which applications are allowed to use it.

A machine that relies entirely on cellular connectivity presents a different picture. Its regular communication, management traffic, and updates all need to be included unless a particular function uses another connection.

Once the communication paths are clear, the individual traffic sources can be measured or estimated without counting the same activity twice.

3. Calculate Baseline Data Usage From Reporting Frequency and Message Size

Suppose a monitoring device sends a 2 KB report every 15 minutes.

Over one day, it sends 96 reports. In a 30-day month, that becomes 2,880 reports. At 2 KB each, the device sends 5.76 MB of application data.

The calculation is:

Monthly data = Message size × Messages per day × Days

2 KB × 2,880 = 5,760 KB = 5.76 MB

We are using decimal units here, with 1 MB equal to 1,000 KB.

The 5.76 MB figure covers the reports leaving the device. It says nothing about what comes back from the server.

If each report receives a 1 KB application response, the complete application exchange is 3 KB rather than 2 KB.

3 KB × 2,880 = 8,640 KB = 8.64 MB

That is almost 3 MB more per month, without changing the reporting frequency or the information contained in the original report.

The calculation still excludes any lower-level protocol overhead not included in those message sizes. We will account for that separately.

What if a device reports only when something happens?

Fixed reporting intervals work well for sensors and other equipment that sends information on a schedule. Many commercial IoT devices do not operate that way.

A vending machine might report its inventory every hour but send payment-related information whenever a customer makes a purchase. An EV charger exchanges information about charging sessions, which may vary considerably between locations.

In these cases, the number of daily events becomes part of the estimate.

Take a payment terminal that transfers a combined 5 KB of application data for each completed transaction. At 40 transactions a day, that would be 6 MB over a 30-day month. At 100 transactions a day, it would be 15 MB.

Neither figure tells us how much the entire terminal consumes. We have counted transaction-related application traffic only, using an assumed exchange size.

But the comparison shows why activity levels matter. The same equipment can generate different amounts of data simply because one location is busier than another.

For deployments where transaction volumes fluctuate, a quiet day and a busy day may be more informative than a single average. Those figures can then be used to build a monthly estimate based on the location's expected activity.

Which message size should you use?

Documentation sometimes gives the size of the information produced by an application rather than the amount transferred over the network.

A 2 KB sensor reading, for example, may be placed inside a larger request and sent over an encrypted connection. The server may also return data that the original specification does not mention.

If the device is available for testing, record both upload and download traffic during a representative number of exchanges.

When the equipment has not yet been deployed, ask the manufacturer or application provider what their traffic figures include. A quoted message size and a measured cellular data total are not necessarily describing the same thing.

4. Account for Background Traffic and Network Overhead

A payment terminal inside a vending machine might go several hours without processing a purchase. That does not necessarily mean its cellular connection is idle.

The terminal may exchange messages with a remote payment service, while the machine controller reports its status to a management platform. Some of these exchanges happen on a schedule; others are needed to maintain application communication.

The traffic can be easy to miss because none of it corresponds to a sale or another obvious event.

For instance, a controller reporting its status every five minutes makes 288 exchanges a day. Even a small message becomes a recurring source of monthly data usage.

The protocol used by the application also makes a difference.

An MQTT application may maintain a persistent connection and exchange relatively small messages. Another system might make separate HTTPS requests whenever it needs to send information. The resulting traffic depends on message sizes, connection setup, security requirements, and application configuration.

Neither protocol tells us the monthly data usage on its own.

A small application message also has to be delivered across the network. IP and transport headers add bytes, TCP may generate acknowledgement traffic, and encrypted connections require additional information during setup and data exchange.

For large file transfers, these extra bytes may represent a small share of the total. The proportion can be much greater when an application frequently exchanges very small messages.

That is why a fixed overhead percentage is a weak substitute for measurements. A 10% allowance might be reasonable for a particular tested configuration, but there is no basis for applying it to every IoT device.

During early planning, an estimated overhead allowance may be unavoidable. It should remain separate from measured traffic so it can be replaced when actual data becomes available.

Check how much the device uses when nothing is happening

One useful measurement is the amount of cellular data a device transfers during a quiet operating period.

Leave it powered on with its normal applications and services running, but without deliberately generating transactions or other user-triggered activity.

Over 24 hours, record how much data passes through the cellular connection.

The result may include application keepalives, routine status messages, management-platform communication, and other background exchanges. Depending on the equipment, that quiet-period usage may represent a meaningful part of the monthly total.

A test device can still give a misleading result if its configuration differs from production. Engineering logs may create traffic that will later be disabled, while a management service that runs in production might not yet be connected.

The useful measurement is the one taken with the software and communication settings the deployed device will actually use.

5. Allow for Retries and Reconnection Traffic

A payment request does not always complete on the first attempt.

The terminal may send information to a remote service but fail to receive the response it expects. From the application's perspective, the operation has not completed. The original request, however, may already have travelled over the cellular connection.

If the terminal sends it again, the repeated request adds more data.

How much this affects the monthly estimate depends on the number of repeated exchanges and their sizes.

Suppose an application normally completes 1,000 exchanges a day, transferring a combined 2 KB per exchange.

If 50 of those exchanges require one additional complete attempt, the extra application traffic would be:

50 × 2 KB = 100 KB per day

Over 30 days, that becomes approximately 3 MB.

In this example, 50 repeated exchanges represent 5% of the original daily count. That percentage is only a calculation assumption, not a typical retry rate for IoT equipment.

The same number of retries would produce a very different result if each exchange involved 20 KB or 200 KB.

Reconnection traffic needs a little more care because not everything involved in restoring cellular connectivity is counted as ordinary billable data.

The mobile network handles registration and other signaling functions. We should not assign an arbitrary amount of data to each of those events.

An application reconnecting to its server is different. It may need to establish a new encrypted connection, authenticate again, or resend information that was not successfully delivered. Each new exchange adds to the data transferred.

How often this happens is worth checking during testing. A device that reconnects once or twice a month is unlikely to generate much additional traffic from those exchanges. If the application reconnects several times a day and resends the same information, the monthly total starts to look different.

There is little value in assuming a severe connectivity problem will occur every month. For planning, use expected operating conditions and any retry information available from testing. Persistent communication problems should be investigated separately rather than treated as normal data consumption.

6. Estimate Data Usage for a Connected Vending Machine

For the calculation, we'll use a vending machine with one cellular connection shared by its payment terminal and controller. It processes 60 cashless transactions a day, sends hourly inventory reports, and reports its status every five minutes. The controller also checks in with its management platform four times daily.

These are assumed operating conditions, not average figures for vending machines. The message sizes are estimates too. We would need measurements from the actual equipment before using the result to choose a data allowance.

Step 1. Count routine application traffic

The assumed exchange sizes cover application-level requests and responses, but not all network overhead. We are also using a 30-day month and decimal units, where 1 MB equals 1,000 KB.

The status reports account for 4.32 MB of the total. In this example, the controller sends one every five minutes. Another machine might report less frequently or send a different amount of information.

We now have 13.56 MB of routine application traffic. The estimate is useful, but we haven't accounted for everything using the connection.

Step 2. Add traffic outside the routine reports

Our machine also needs an allowance for protocol overhead, remote management, and the occasional repeated transfer.

For illustration, we'll use these monthly amounts:

These amounts are placeholders, not typical figures for vending equipment. The 3 MB allowance, for example, would need to be replaced once we know how much traffic the connection transfers beyond the application messages already counted.

One precaution matters here: the same bytes must not appear in both tables. If a measurement already includes network overhead or a management exchange, we shouldn't add it again.

Combining our assumptions gives us:

For early planning, we could treat this as approximately 20 MB per month, before adding any buffer or scheduled software downloads.

Step 3. Check the machine's actual configuration

Our example assumes a fairly simple machine. It doesn't include a connected advertising screen downloading new media, frequent transfers of detailed operating logs, or other applications that may be installed on more advanced equipment.

There may also be more than one modem involved. Some payment terminals use a separate cellular connection, which means their traffic belongs to a different SIM and a different allowance.

Before using the 20 MB estimate, we'd check the machine's configuration against the original list of traffic sources. That may lead to another row in the calculation, or it may show that some of the traffic we've counted doesn't use this connection at all.

7. Plan for Software Updates and High-Usage Months

The 20.06 MB we calculated for the vending machine covers a normal month without major software downloads. A firmware update would be additional traffic.

For the next calculation, assume 40 MB is transferred over cellular during an update. The monthly estimate then rises to 60.06 MB.

The 40 MB is an assumed transfer volume, not a standard firmware size. Some machines receive a complete firmware image, while others download only changed components. The amount transferred depends on the update method and equipment.

This also assumes 40 MB is the amount transferred over the cellular connection. If the figure comes from the size of an installation package, the actual download traffic may be somewhat different.

Some update systems retrieve additional files or make another download attempt when something goes wrong. Those transfers need to be included when they occur, rather than assuming the advertised package size always equals the final cellular usage.

An update across the entire fleet

A 40 MB download may not look especially large for one machine. For an operator managing 500 machines, it represents 20 GB of additional traffic if every device downloads the same amount during one billing period.

That traffic would come on top of normal operations.

Some operators distribute updates in stages, particularly when they want to check the results on a smaller group of machines before deploying them everywhere. If the rollout also crosses billing periods, the monthly increase may be spread out.

Other updates cannot wait. An urgent security fix might need to reach the entire fleet within a short period, regardless of how the monthly data allowance was originally planned.

It is worth finding out how the equipment receives updates before choosing a data plan. A machine that downloads firmware over local Wi-Fi, for example, would not use cellular data for that download unless the transfer was routed over its cellular connection.

For our estimate, we'll keep routine traffic and scheduled downloads separate. That gives us a normal-month figure of approximately 20 MB and an update-month example of approximately 60 MB.

8. How Data Usage Estimates Change Across IoT Industries

The vending example works well for equipment that handles transactions, sends status reports, and receives occasional instructions. Those activities are also found in POS terminals, ATMs, and EV chargers, although the applications and the amount of information exchanged will differ.

Digital signage is a different case. A billboard can spend much of its time playing content stored locally, using relatively little data for monitoring. When a new advertising campaign arrives, it may download hundreds of megabytes or several gigabytes of media files.

For that system, knowing how often a player reports its status won't tell us much about its total monthly consumption.

The following table shows where the main differences lie.

Transaction-based equipment

For POS terminals and ATMs, transaction-related traffic can be calculated in much the same way as our vending example. We need an estimate of how many transactions take place and how much data is exchanged for each one.

The equipment provider may already have this information.

Payment systems often use manufacturer-specific software and communication arrangements, so a generic transaction size may not be very useful. It is better to work with the documented traffic profile of the actual terminal or ATM application.

Normal management and maintenance activity still needs to be included if it uses the same connection.

EV charging equipment

An EV charger doesn't generate the same amount of application traffic throughout the day. It may exchange routine status information while idle, then communicate more frequently during charging sessions.

The management protocol, its configuration, and the number of sessions all influence usage. A charger using OCPP, for example, exchanges messages with its backend according to the supported protocol version and how the system has been configured.

For an estimate, we'd want to know how often the charger reports its status, the expected number of charging sessions, and what other services share its connection.

Firmware downloads should be measured separately because they may be much larger than routine operational messages.

Digital signage and billboards

For a digital signage player, start with the content schedule.

How many files does the player download? What are their compressed file sizes? Does the entire campaign change each week, or are only a few assets replaced?

If a player downloads 500 MB of new media every week, the content transfers alone would account for approximately 2 GB over four weeks. Monitoring messages and management traffic would come on top of that.

The same player could use far less data if its content rarely changes.

For this type of deployment, file sizes and download schedules are usually more informative than the number of small application messages.

Different locations, different consumption

Even within one industry, identical devices may not consume similar amounts of data.

A vending machine in a busy railway station could process far more transactions than the same model in a small office. An EV charger installed at a frequently used public charging site may report more charging activity than one at a quiet private location.

We don't necessarily need a separate estimate for every installation. A few realistic operating profiles are usually enough to show how traffic changes between quieter and busier locations.

Those differences become especially useful when we calculate usage across the fleet.

9. Calculate Monthly Data Usage for an Entire IoT Fleet

A per-device estimate becomes more useful when we know how many machines will operate under similar conditions.

For 500 devices consuming 20 MB each, the expected monthly total is about 10 GB.

Fleet usage = Number of devices × Monthly usage per device

That works for a group of identical machines with similar activity. A mixed deployment needs a little more detail.

Imagine a vending operator connecting 400 machines. Three hundred are standard machines expected to use around 20 MB each per month. Another 100 have additional connected functions and are expected to consume approximately 50 MB each.

Rather than apply one average to the whole fleet, we can calculate the groups separately.

The 11 GB total covers a normal operating month, before any additional buffer or fleet-wide software downloads.

Now suppose the operator plans to add another 200 standard machines. Based on the same 20 MB estimate, those devices would add approximately 4 GB to the monthly total.

The calculation doesn't require a new model every time the fleet grows. As long as the new machines operate under similar conditions, their expected consumption can be added to the appropriate group.

A different equipment model, management platform, or operating schedule may justify creating another profile.

For a mixed fleet, the calculation becomes:

Fleet usage = Sum of (number of devices in each group × monthly usage per device in that group)

The group sizes and usage figures are what matter here. A fleet-wide average can still be useful for reporting, but it is easier to plan growth when we know which types of devices account for the expected traffic.

10. Choose a Data Allowance and Build in a Reasonable Buffer

Our vending-machine calculation produced approximately 20 MB for a normal month and 60 MB for a month that includes the example software download.

Those figures give us something to work with when evaluating cellular plans. They don't yet tell us which allowance to choose.

We still have estimated traffic that hasn't been measured on actual equipment, and some monthly variation is unavoidable.

Suppose we provisionally allow an additional 25% above the normal-month estimate.

20.06 MB × 1.25 = 25.075 MB

Rounded for planning, that's approximately 25 MB.

The 25% is only an example. It isn't a standard buffer for IoT deployments, and there is no guarantee it will cover every possible increase.

For a device with stable reporting intervals and a well-tested application, measured usage may stay within a fairly narrow range. A machine that frequently downloads new content or receives additional management instructions can behave differently.

The size of the buffer should reflect what we know about the equipment, including the difference between normal and busier operating periods.

Allow for months with larger transfers

Applying the same 25% calculation to our update-month estimate gives:

60.06 MB × 1.25 = 75.075 MB

That is approximately 75 MB, compared with 25 MB for the normal month.

We shouldn't assume the machine needs 75 MB every month simply because it occasionally downloads an update. Nor should we assume that a 25 MB allowance will be sufficient whenever maintenance takes place.

The choice depends partly on when those larger transfers occur and how the connectivity plan handles them.

For equipment with scheduled software downloads, it is useful to keep the expected download volume visible in the calculation rather than burying it inside a general buffer.

The same applies to unusually large diagnostic transfers or digital signage content updates.

Individual allowances versus pooled data

Consider ten connected machines using an average of 30 MB each per month.

That average doesn't tell us whether every machine will fit comfortably within a 30 MB individual allowance. Some may use 10 MB, while others reach 60 MB or more.

If each SIM has a fixed allowance, the higher-usage machines need enough capacity for their own traffic, regardless of what the other devices consume.

A pooled-data plan may allow eligible devices to share a common allowance instead. This can be useful when usage varies between locations, although the exact terms depend on the provider and plan.

A pooled allowance doesn't make the traffic disappear. A few unusually active devices can still consume much of the available data.

For a larger deployment, we'd compare the expected fleet total with the way usage is distributed between individual connections. That tells us more than an average alone when evaluating plan options.

11. Validate Your Estimate Before Scaling the Deployment

The calculations are useful for early planning. Before ordering connectivity for hundreds of devices, we'd want to see how close they come to actual usage.

A small pilot can answer questions that equipment specifications don't always cover.

For vending machines, the test group should include normal payment activity, inventory reporting, remote management, and the configuration intended for production.

It also needs to represent the locations where the machines will operate. Testing only a quiet machine may produce a good estimate for low-activity locations but leave us short of information about busier sites.

The measurement should include data uploaded and downloaded through the cellular connection.

Different monitoring tools may report different figures. An application log might count the information exchanged with the backend, while a router or modem can report traffic passing through the cellular interface.

The connectivity provider's usage records are especially useful because they show what is accounted for under the service.

These measurements may not match exactly. They can use different reporting intervals or count traffic at different points in the communication path.

Compare the original estimate with measured usage

During the pilot, we'd compare the main parts of the estimate with traffic observed on the equipment.

A comparison may reveal that one of the original assumptions was wrong.

Perhaps a status report runs every minute rather than every five minutes. Maybe the management platform requests information more frequently than the documentation suggested.

These are the details worth finding before the deployment reaches several hundred devices.

If usage differs from the estimate, check whether the comparison covers the same period and whether any traffic has been counted twice. Application-level figures and provider-reported totals are not always directly interchangeable.

Give the pilot enough time

One day of testing won't necessarily capture the machine's normal workload.

Transaction volumes may differ between weekdays and weekends. Diagnostics may happen only occasionally, and a firmware update might not occur during the first week.

A pilot covering several representative operating periods gives a better view of routine consumption.

If the test finishes before a planned maintenance cycle, the missing update traffic can remain as a separate estimate until a real transfer has been measured.

Once the devices are deployed, the original calculation is still useful. Comparing it with monthly consumption can reveal changes in reporting frequency, management activity, or software behavior before those differences affect the entire fleet.

12. Turn Your Data Estimate Into a Cellular Connectivity Plan

A completed usage estimate gives the team a clearer basis for comparing connectivity options. It shows approximately what each device needs, how much the fleet may consume, and where occasional increases are likely.

There are still other requirements to consider.

A vending machine might use very little data each month, but payment communication needs to work reliably whenever a customer makes a purchase. A digital signage player may download large media files without needing continuous high bandwidth, provided the content arrives before it is scheduled to appear.

Those are different connectivity requirements, even when the monthly data totals are similar.

The locations of the devices matter as well.

A fleet spread across several cities or states may operate in areas with different cellular coverage. For international deployments, network availability, roaming arrangements, and local connectivity requirements can vary further.

It is worth checking whether the selected hardware and SIM arrangement can provide the required network access at each location, alongside the data allowance.

For larger fleets, the ability to monitor consumption also becomes important. A plan that looks appropriate for the first 100 devices may need adjustment as the deployment expands or new equipment models are introduced.

Usage estimates are rarely fixed for the entire life of a deployment. Software changes, added functions, and different operating conditions can all affect how much data devices transfer.

The original calculation gives the operator a basis for selecting connectivity and a reference point for checking whether the deployment continues to behave as expected.