You find out about the data cap the worst possible way: a client calls because the link crawls or stops, and only then do you learn that the Starlink terminal behind your MikroTik burned through its monthly allowance two weeks early. Starlink has changed its plans and their limits more than once, and some of them carry a cap measured in terabytes. For a small ISP or a business sharing one dish among many users, that number is reachable. The fix is not complicated, but it needs to be in place before the problem, not after.
Find out what your plan actually counts
Log in to your Starlink account and note three things: the size of the cap, the date your billing cycle resets, and what happens when you exceed it (slower speeds, or a hard stop). These details change with the plan and over time, so read them from your own account rather than trusting a forum post, this one included. If it is unclear whether upload counts against the cap, measure download plus upload. You will overestimate slightly, which is the safe direction to be wrong in.
Read the byte counters on the WAN interface
RouterOS keeps cumulative byte counters per interface. Check the one facing the Starlink terminal (here ether1):
/interface print stats where name=ether1The rx-byte and tx-byte values count everything since the router last booted. They are the raw material, but a single reading says nothing about the month, so you need to record them regularly.
Log the counters once a day with a script and a scheduler
/system script add name=datacap-log source={
:local wan "ether1"
:local rx [/interface get $wan rx-byte]
:local tx [/interface get $wan tx-byte]
:log info ("datacap wan=" . $wan . " rx=" . $rx . " tx=" . $tx)
}
/system scheduler add name=datacap-log interval=1d start-time=00:05:00 on-event=datacap-logEach day a line like datacap wan=ether1 rx=... tx=... lands in the log. Consumption for a day is the difference between two consecutive readings. Make sure the log is not wiped between readings, for example by sending it to a remote syslog.
Handle reboots, or your numbers will lie
The counters go back to zero when the router reboots. If today's reading is lower than yesterday's, do not subtract: a reboot happened, and the real consumption since then is just today's value. The same applies to a counter that reads exactly zero because of a glitch: do not take it as a reboot without cross-checking against the uptime in /system resource print. Ignoring this is the most common reason homemade data-cap trackers show a month with half the traffic that really went through.
Project the month, do not just add it up
The useful number is not what you have used so far but where you will end up. A simple projection:
projected = used_so_far / days_elapsed * days_in_cycleIf you have used 40% of the cap by day 10 of a 30-day cycle, you are heading for 120%. Set warnings at roughly 70%, 85% and 95% of used cap, and treat "projected over 100%" as the earliest signal of all, since it still leaves time to act.
Have a backup link ready before you need it
An alert only helps if you have somewhere to go. Keep a second uplink (a 4G/5G modem or another ISP) configured permanently with a higher route distance, so the router switches over when you lower the priority of the Starlink route:
/ip route add dst-address=0.0.0.0/0 gateway=<starlink-gateway> distance=1 comment="starlink"
/ip route add dst-address=0.0.0.0/0 gateway=<backup-gateway> distance=2 comment="backup"Keep the backup route enabled all the time and only change the Starlink one. If your remote management reaches the router through the same link you are about to cut, a two-step change that gets interrupted halfway can lock you out of your own router.
Why do it this way
Data caps punish exactly the kind of customer who depends most on Starlink: remote sites, rural ISPs, and anyone with no real alternative. Going over rarely announces itself gradually. It shows up as a throttled link in the middle of a billing cycle, with the customers already complaining. Measuring consumption yourself, instead of waiting for the provider's dashboard to tell you, gives you days or weeks of margin to reduce heavy usage, add a backup uplink, or move customers to another plan. The cost is one script and a scheduler entry.
How MoniTik helps
MoniTik includes a data cap meter for exactly this. You enter the cap in GB for the WAN interface that faces the Starlink terminal, and it tracks consumption using a rolling 30-day window (or a fixed cycle if you give it your reset date), handles router reboots correctly, and emails you as usage crosses warning thresholds. You get the projection without maintaining scripts on every router. Note that it measures and warns; switching to a backup link is still something you do yourself.
Camila focuses on routing, VPNs, and hardening MikroTik deployments for small and mid-size networks.