MikroTik RouterOS v7 Packet Loss Monitoring: Calculate Packet Loss Percentage Using Scripts

Packet loss is one of the most useful indicators of WAN and path quality, but a successful ping to one destination does not prove that a connection is healthy. With RouterOS v7, you can run repeatable ICMP tests, calculate the percentage of unanswered probes, log the results, and schedule checks. RouterOS also has an ICMP probe in Netwatch that already exposes loss statistics, so this guide covers both a custom script and the native monitoring option.

The examples use RouterOS v7 syntax. Test them manually on your own device and adjust the target, probe count, interval, permissions, and schedule to match your network. ICMP can be filtered or rate-limited by remote hosts, so use a stable target that is expected to answer pings and compare more than one point in the path.

What packet loss percentage means

Packet loss is the share of transmitted test packets for which no matching response was received before the timeout. The calculation is:

Packet loss (%) = ((Packets sent − Packets received) ÷ Packets sent) × 100

For example, if the router sends 20 echo requests and receives 18 replies, 2 packets were lost:

((20 − 18) ÷ 20) × 100 = 10%

Loss is measured for the test interval and destination. It is not automatically the same as application-level loss, TCP retransmissions, or drops on a particular interface.

Run a baseline ping test first

Before scripting, test the target from the router terminal:

/ping address=1.1.1.1 count=20 interval=200ms

RouterOS reports sent and received packet totals, packet-loss percentage, and round-trip time statistics. This establishes whether the target responds and gives you a baseline. You can also specify a source address, interface, or routing table when diagnosing a particular WAN path; use the options supported by your installed RouterOS version.

If the target does not answer, do not immediately conclude that your ISP is dropping packets. The remote host or an intermediate network may filter ICMP. Test your default gateway, a provider-side address if available, and one or more reliable external endpoints.

Create a RouterOS v7 script to calculate packet loss

The following script runs a batch of pings, reads the final summary row returned by the ping command in value format, calculates lost packets from the sent and received totals, and writes the result to the RouterOS log. The example uses 20 probes to 1.1.1.1; change the target to an address appropriate for your network.

:local target "1.1.1.1"
:local probes 20

:local pingData [/tool/ping address=$target count=$probes interval=200ms proplist=sent,received as-value]

:if ([:len $pingData] = 0) do={
    :log warning ("Packet-loss check: no result returned for " . $target)
    :error "Ping returned no result"
}

# The final item contains the aggregate ping summary.
:local summary [:pick $pingData ([:len $pingData] - 1)]
:local sent ($summary->"sent")
:local received ($summary->"received")

:if ($sent = 0) do={
    :log warning ("Packet-loss check: zero probes sent to " . $target)
    :error "No ping probes were sent"
}

:local lost ($sent - $received)
:local lossPercent (($lost * 100) / $sent)

:log info ("Packet loss to " . $target . ": " . $lossPercent . "% (" . $lost . " lost of " . $sent . ")")

How it works:

• target is the IP address being tested. An IP address avoids mixing DNS resolution failures into an ICMP reachability test.
• probes sets the number of echo requests in each sample.
• as-value returns the ping output as structured values that the script can read by field name.
• The script selects the final item in the returned list, which is the aggregate summary for the ping batch.
• It calculates lost packets as sent minus received and computes the loss percentage. RouterOS script arithmetic is integer-based here, so this example reports a whole-number percentage.
• :log info records the result in the system log.

Paste the commands into a single script block in the terminal or create a script under System → Scripts in WinBox. Keep the commands together in one script scope: RouterOS local variables do not persist between separate terminal command lines. If your RouterOS build returns a different structure, inspect the raw value first with a short test such as :put [/tool/ping address=1.1.1.1 count=3 as-value proplist=sent,received,packet-loss] and adapt the summary selection to the returned data.

Store the script and run it manually

To save the example under a reusable name, add it through System → Scripts in WinBox, set the name to packet-loss-check, paste the script source, and assign only the policies it needs. The script reads ping results and writes to the log; it does not change routes or firewall configuration. Give it the read and test policies required for those operations, then run it manually.

Check the output with:

/log print where message~"Packet loss to"

Run several samples at different times before treating a single result as evidence of a persistent problem. A short burst can reflect transient congestion, ICMP rate limiting, or a temporary remote-host issue.

Schedule recurring packet-loss checks

After confirming that the script runs correctly by hand, you can schedule it. In WinBox, open System → Scheduler, add an entry named packet-loss-every-5m, set the interval to 5m, and set On Event to packet-loss-check. Ensure the scheduler entry has permission to run the script and the script has the policies required by its commands.

The equivalent CLI command is:

/system/scheduler/add name=packet-loss-every-5m interval=5m on-event=packet-loss-check policy=read,test

Choose an interval that makes sense for the device and the monitoring goal. Twenty probes every five minutes is a light diagnostic sample for many routers, but very frequent tests, large probe counts, or many monitored destinations create additional traffic and script work. Avoid overlapping runs; make sure a test finishes before the next scheduled run begins.

To verify that the scheduler is active and running, use:

/system/scheduler/print detail where name="packet-loss-every-5m"
 /log print where topics~"script"

The scheduler’s run count and the system log help identify whether the script is being invoked and whether it is failing due to permissions or a syntax issue. For general automation patterns, see the official RouterOS Scheduler documentation.

Use Netwatch ICMP probes for built-in loss statistics

For ongoing host monitoring, RouterOS v7 Netwatch can be simpler than maintaining a custom ping parser. Its icmp probe sends a series of echo requests and exposes sent count, response count, loss count, loss percentage, round-trip time, and jitter. It can also run a test script after every probe test.

Example: create an ICMP probe with 20 packets every minute:

/tool/netwatch/add name=wan-loss-check host=1.1.1.1 type=icmp interval=1m packet-count=20 packet-interval=200ms test-script=":log info (\"Netwatch loss to \" . $host . \": \" . \$\"loss-percent\" . \"%\")"

Netwatch exposes the per-test loss value to its scripts as $"loss-percent", alongside $"sent-count", $"response-count", and $"loss-count". You can inspect the configured probe and its latest statistics with:

/tool/netwatch/print detail

Be aware that Netwatch ICMP probes have threshold defaults even when you do not configure them: in particular, the default loss threshold is 85%, average RTT threshold is 100 ms, and jitter threshold is 1 second. A probe can be marked down because one of these thresholds is crossed, not only because the host is unreachable. Review the configured thresholds and statistics before interpreting the up/down state. Netwatch scripts also run in a restricted policy context, so keep their commands within the documented permissions.

For host state monitoring, thresholds, and scripts that react to probe changes, see MikroTik Netwatch: Uptime Monitoring and Automated Actions.

Understand where packet loss occurs

A single ping target only measures the round trip to that target. To narrow down the location of a problem, compare results at several points:

• LAN gateway: loss here can point to a local cable, switch, Wi-Fi, client, router CPU, or LAN congestion issue.
• ISP next hop: loss between the router and a provider gateway can indicate an access-link or provider-side issue, although ICMP prioritization can distort results.
• External IP address: loss only beyond the provider edge can indicate upstream routing, transit congestion, or remote ICMP filtering.
• Application endpoint: a host may respond to ping while its TCP or HTTPS service is unhealthy. Use an application-level check when service availability is the real objective.

Also inspect interface counters and link state. CRC/FCS errors, queue drops, overruns, wireless retries, or a saturated uplink can help explain loss that an end-to-end ping alone cannot localize. The site guide MikroTik CLI Troubleshooting: Advanced Diagnostic Techniques covers additional diagnostics, while LibreNMS SNMP Monitoring for MikroTik explains how to collect longer-term device metrics.

Interpret the results carefully

Observed loss	What it may indicate	What to check next
0%	No ICMP loss in this sample	Repeat at busy and quiet times; check latency and application performance too
Occasional low loss	Transient congestion, Wi-Fi interference, or ICMP rate limiting	Increase sample duration and compare multiple targets and hops
Persistent loss to the gateway	Local link, interface, switching, wireless, or router load issue	Inspect interface errors, signal quality, CPU, and queue counters
Loss begins beyond the ISP gateway	Provider or upstream path issue, or remote ICMP filtering	Compare traceroute and contact the provider with timestamps and repeated samples

Do not treat one arbitrary percentage as a universal service-level threshold. Acceptable loss depends on the application, path, measurement interval, and provider agreement. Voice, interactive sessions, and real-time applications can be affected by even small bursts, while a short ICMP sample may exaggerate or miss user-visible problems.

Common problems and troubleshooting

The script logs an empty or missing value

Inspect the raw as-value output on the exact RouterOS version and confirm the fields requested in proplist. The summary is the final item in the batch output in the example. If the structure differs, adjust the selection rather than assuming the first item contains aggregate totals.

The target shows 100% packet loss

Try the router’s gateway and another known ICMP-responsive address. Confirm that the router has a valid route and source address. Some hosts and networks deliberately rate-limit or block echo requests.

The scheduler does not run the script

Check the scheduler’s on-event name, enabled state, start time, interval, and policy. Confirm that the named script exists and that its required policies are permitted by the scheduler entry. Review the script error messages in the log.

Packet loss is visible only during busy periods

Compare ping results with interface traffic, queue drops, CPU load, and wireless statistics at the same time. A scheduled five-minute sample can miss a short burst, so increase sampling frequency temporarily during diagnosis or use a dedicated monitoring platform for continuous history.

Best practices for reliable monitoring

• Use more than one stable destination and compare a local gateway, provider hop, and external endpoint.
• Keep the probe count and interval consistent so results can be compared over time.
• Log timestamps, target addresses, sent/received totals, and loss percentages; retain logs off-device if you need long-term history.
• Use Netwatch ICMP when its built-in statistics and thresholds meet the requirement.
• Do not trigger route changes from one failed sample. Require repeated failures and design failover logic carefully to avoid flapping.
• Keep scripts short, assign least-privilege policies, and test them manually before enabling a scheduler.

Official MikroTik documentation

• RouterOS Ping
• RouterOS Scripting
• RouterOS Netwatch
• RouterOS Scheduler
• RouterOS Diagnostics and Monitoring

Conclusion

RouterOS v7 gives you several ways to monitor packet loss. A custom script can run repeatable ping batches, calculate the percentage from sent and received totals, and record the result for later review. Netwatch provides native ICMP loss statistics and threshold-based monitoring with less custom code. Whichever approach you choose, test multiple points in the path, account for ICMP filtering, and correlate loss with interface and application metrics before deciding where the fault lies.

---

Check our list of MikroTik guides