How IJA Verify Works: Monitoring Your Network From the Inside Out

When something goes wrong with a business internet connection, there is a predictable sequence of events. A staff member notices the connection is slow or down. They call IT support or the internet provider. The provider checks their monitoring systems, reports that the connection appears up from their end, and asks the customer to run a speed test. The speed test shows reasonable results. The provider closes the ticket. The problem persists.

This sequence happens because the provider's monitoring system is measuring something different from what the customer is experiencing. The provider monitors from their Network Operations Centre (NOC) to the customer's demarcation point — the physical handover between their network and the customer's premises. That measurement tells them the last mile is up. It tells them nothing about what the customer actually experiences.

IJA Verify was built to close this gap. This article explains how it works, what it measures, and why the monitoring direction matters for making SLAs contractually meaningful rather than aspirationally worded.

The Monitoring Direction Problem

Every managed network service provider monitors something. The question is where the monitoring starts and ends.

The industry standard is to monitor from the NOC outward to the customer demarcation point. This is the most convenient measurement for the provider — it tells them whether their infrastructure is delivering what they contracted to deliver up to the handover point. It is also the least useful measurement for the customer — it does not capture what happens inside the customer's premises, or how the connection performs across the wider internet.

A connection can pass this monitoring with flying colours while simultaneously delivering a terrible experience. The last mile is up. The backhaul is up. The provider's SLA is satisfied. And the customer's VoIP calls are choppy, their cloud applications are slow, and their video conferences are dropping every twenty minutes.

The reason is that the problems affecting real user experience often occur beyond the demarcation point or beyond the provider's network entirely — in the customer's internal network, in the transit between the provider and international peering points, or in the throughput to real internet servers as opposed to local CDN nodes.

How IJA Verify Works

IJA Verify monitors from inside the customer's premises outward to the real internet. The measurement direction is reversed — instead of the provider measuring toward the customer, the monitoring is conducted from where the customer is toward where their applications and data live.

The hardware. A Raspberry Pi is installed at the customer's premises. This is a small, low-power device that runs continuously, conducting monitoring tests and sending telemetry to IJA's systems. It is connected to the customer's network — on the business VLAN, behind the router — so it measures what the customer's devices actually experience.

PingPlotter probes. PingPlotter runs continuously on the Raspberry Pi, sending packets to multiple international endpoints and recording latency, packet loss, and jitter at each hop. This provides a continuous real-time view of connection quality from the customer's premises outward — not from the NOC inward.

When a VoIP call degrades, PingPlotter data shows exactly where the degradation is occurring. Is it inside the customer's network? At the ISP's router? In the transit between the ISP and international peers? The hop-by-hop visibility makes problems diagnosable rather than mysterious.

iperf3 throughput tests. On a scheduled basis, iperf3 runs throughput tests from the Raspberry Pi to an IJA server hosted on AWS in London. This measures true internet throughput — the actual speed at which data can be transferred across the entire path from the customer's premises to a real server on the real internet.

This is a fundamentally different measurement from a speed test to a local CDN node. A CDN node may be located within Ghana or in a nearby country — the test measures performance to that nearby server, not to the overseas servers that business applications actually use. iperf3 to London measures the complete path: the last mile, the ISP's backhaul, the international transit, and the final hop to the destination server.

A business whose connection tests at 45Mbps to a local CDN but 8Mbps to the London server has a genuine throughput problem on the international path — which will directly affect cloud application performance, overseas VoIP calls, and any application hosted outside Ghana.

Zabbix telemetry collection. All telemetry from the Raspberry Pi probes — PingPlotter results, iperf3 results, router metrics — is collected by Zabbix and stored for historical analysis. Zabbix alerts when predefined thresholds are crossed: latency above X milliseconds, packet loss above Y percent, throughput below Z Mbps.

When an alert fires, IJA's team is notified. The investigation begins with IJA, not with the customer calling to report a problem.

Grafana dashboards. All telemetry is visualised in Grafana — a dashboard platform that presents monitoring data in clear, readable graphs. Every IJA Verify customer receives their own Grafana login, giving them access to the same data IJA's team sees.

The dashboard shows current and historical latency, packet loss, throughput, and uptime. It shows failover events — when the primary connection failed and the secondary took over, and when the primary recovered. It shows capacity trends over time, which informs decisions about whether the contracted bandwidth is still adequate for the business's current usage.

The Four Pillars

IJA Verify is structured around four measurement dimensions:

Availability. Is the connection up? When did it fail, and for how long? Dual WAN configurations show the status of both links independently. Failover events are logged with precise timestamps.

Quality. How does the connection perform in real time? Latency, packet loss, and jitter — measured continuously from the customer's premises to multiple international endpoints. This is the dimension most directly correlated with VoIP and video conferencing quality.

Capacity. What is the actual throughput to the real internet? Scheduled iperf3 tests to the London server provide a regular benchmark against the contracted speed and identify degradation over time.

Visibility. All of the above, surfaced in a customer-facing Grafana dashboard. Not a monthly report or a summary. Live data, the same data IJA's team monitors.

Why This Makes SLAs Contractual

An SLA based on NOC-to-demarcation monitoring is difficult to enforce because the measurement scope is too narrow. If the customer experiences poor performance but the provider's monitoring shows the last mile is up, there is no contractual basis for escalation.

An SLA based on IJA Verify monitoring is different. The measurements capture the full customer experience — from the premises, across the last mile, through the backhaul, across international transit, to a real internet server. When the monitoring shows that latency has exceeded the SLA threshold for X hours, or that throughput has fallen below the contracted level for Y consecutive tests, there is documented evidence that the SLA has been breached.

More importantly, IJA reacts to monitoring alerts — not to customer complaints. When PingPlotter shows packet loss increasing, IJA investigates before the customer notices a degraded VoIP call. When throughput trends downward over several days, IJA identifies the cause before it becomes a business-impacting outage.

This is the practical difference between a managed service and a reactive support contract: one responds to problems after the customer calls; the other prevents problems from reaching the customer's awareness in the first place.

What the Customer Sees

A customer with IJA Verify deployed receives a login to their Grafana dashboard. The dashboard is not a polished summary with selected metrics — it is the same operational view that IJA's team uses.

The customer can see their current connection status, today's latency and packet loss graphs, this week's iperf3 results, and any alerts that have fired. They can look back at any historical period to see how the connection has performed over time.

This transparency is deliberate. IJA's positioning — trust and verify — requires that customers can verify the service they are receiving. A customer who can see that their connection has maintained sub-20ms latency and zero packet loss for the past thirty days has evidence that they are receiving what they contracted. A customer who sees that there was a failover event on Tuesday at 14:23 lasting six minutes, during which the secondary Starlink connection carried all traffic, has a complete record of how their infrastructure responded to a real failure.

The dashboard is not a promise. It is a login.

IJA Technologies deploys IJA Verify as standard on every managed service contract. Talk to us about monitoring your network.