Automating Censorship Checks With the Neumon API on Your Servers

Australian internet users have grown familiar with the inconsistencies between advertised speeds and real-world performance. Whether you are streaming Kayo Sports from Adelaide, hosting a game server out of Brisbane, or running a remote work setup in Hobart, the behaviour of your connection depends on which Australian ISP sits between your device and the wider internet. The Net Neutrality Monitor project, hosted at neumon.org, makes its probe network, blacklist database, and country-by-country results available over a public interface, allowing curious users, journalists, and sysadmins to verify filtering behaviour without depending on a single operator's word.

For infrastructure teams, manual spot checks are a poor substitute for continuous verification. The API described here exposes endpoints for queuing probes, retrieving responses, and exporting filtered feeds. Once wired into a small server, the API becomes a quiet watchdog that logs unexpected blocking patterns, flags DNS poisoning attempts, and keeps an audit trail of what Australian ISPs and overseas networks have done across the past weeks or months.

Understanding What the API Exposes

The API is structured around three practical categories of data: probe results, blacklists, and aggregate statistics. Each category maps to a different need. Probe results are best for per-target verification, such as confirming whether a specific URL or IP is reachable from inside Australia. Blacklists describe the curated lists the project maintains and updates, useful when you want to cross-reference your own logs against a community-curated dataset. Aggregate statistics summarise response patterns across time windows and are useful for trend analysis.

Every endpoint returns JSON by default, which keeps integration light. There is no SDK to install and no heavy client to maintain; a simple HTTP client of the kind found in Python, Go, or any shell-friendly tool is enough. Rate limits are conservative, reflecting the volunteer-supported nature of the project, so architecture planning should assume batched requests and polite intervals rather than aggressive polling. Authentication is handled with a free personal token, which can be requested through the help center once you create an account.

The endpoints are also designed to be cache-friendly. Probe responses include a last-checked timestamp, a confidence flag, and the originating probe node, meaning your server can store the result, decide whether it has drifted beyond your freshness window, and only re-query when necessary. That design matters once you start scaling beyond a handful of targets, because polling every few minutes for thousands of hosts would waste tokens and bandwidth.

Wiring the API Into a Small Server

A typical setup starts with a single modest machine running in a Sydney or Melbourne data centre, ideally on a different ISP than the one you intend to investigate. Separation matters: if your monitoring infrastructure sits on Telstra and you want to know whether Optus filters a given destination, the path between your probe and the API must not itself transit the network you are auditing.

Once you have an isolated host, the next step is to define a target list. The list should mix commonly blocked domains with services your own users rely on, including government services, banking portals, and content categories that have historically attracted filtering in Australia. A small JSON file with categories and check frequencies is enough to drive the automation, and you can grow the file as you learn more about what matters.

For the polling loop, a simple cron job or systemd timer will do. Each tick, the script reads the target list, issues a probe request, and writes the response to a local time-series store such as SQLite, InfluxDB, or even a flat CSV if your volume is small. The crucial detail is to capture not only the verdict but the metadata: which probe answered, how long it took, and which blacklist tag, if any, was attached.

• Reserve a dedicated host that does not share an ISP with your targets.
• Store full probe metadata, including origin node and round-trip time.
• Refresh cached entries only when they pass your freshness threshold.
• Tag every measurement with the requesting user or system so that later audits stay readable.

Interpreting Results the Way the Project Intends

Probe data carries several fields that look similar at first glance but mean different things in practice. A small cheat sheet for the most common response fields helps when reading results:

• BLOCKED: the probe could not reach the destination from the country requested.
• FILTERED: a transparent proxy intercepted the request and returned a block page.
• RESOLVED: DNS returned an answer, but the destination was not validated further.
• NO_DATA: the probe could not perform the test, often because of a transient network issue.

Cross-referencing your own results against the published country pages helps separate real censorship from mundane connectivity faults. A regional NBN outage in Perth, for example, may show up as a probe failure even though no deliberate filtering is involved. The project publishes a reading probe data guide that walks through the same fields and shows how to distinguish each failure mode.

When results conflict with what you expected, the response payload usually tells you where the disagreement began. Probe nodes report their own ASN and city, so you can see whether the check was performed from Sydney, Vienna, or São Paulo. Comparing equivalent checks across two Australian nodes can be revealing: identical outcomes suggest a clear network-level block, while divergent outcomes suggest resolver-level interference or a geo-restricted service that simply returns a different page to Australian visitors.

Automating Checks Across Australian Networks

Automation pays off the moment you scale beyond a handful of URLs. A bash-driven prototype works for the first weeks, but a real deployment needs logging, retries, and a way to alert on anomalies. Many Australian operators, including Aussie Broadband and a handful of hosting providers, expose IPv6 alongside IPv4, and your probe script should query both families because filtering is not always symmetrical between them.

A small comparison helps in choosing the right scheduling approach:

Approach	Setup cost	Token usage	Best fit
Direct cron job	Low	High if unchecked	Small lists under fifty targets
Queue-based worker	Medium	Predictable	Larger fleets, mixed priorities
Event-driven triggers	Medium-High	Minimal	Reactive auditing on user reports
Batch endpoint with cache	Low	Low	Long-running dashboards

Each approach has trade-offs. A queue-based worker scales comfortably for a small business in Brisbane running customer-facing checks, while an event-driven pipeline is more useful for journalists who want to be notified the moment a story-relevant URL starts behaving differently. The batch endpoint with caching is the most economical if your goal is a passive dashboard that refreshes every few hours rather than a live trigger system.

Australia's regulatory environment adds another reason to automate. The Australian Communications and Media Authority maintains block lists under sections of the Telecommunications Act 1997, and these lists shift without a public changelog. Automated checks let you detect when a previously reachable service suddenly returns an ACMA-style notice, which would otherwise pass unnoticed inside a busy production environment. Similar patterns have been observed in the wake of Online Safety Act compliance actions, where overseas services serving Australian users occasionally become unreachable for short windows.

Common Use Cases Worth Building First

A handful of use cases deliver immediate value and are quick to assemble. Newsroom auditing is one: a small probe loop running overnight can publish a daily snapshot of whether major Australian and global news outlets are reachable from inside the country, useful for press freedom work in Canberra and beyond.

A second use case is ISP transparency for small and medium businesses. Regional operators in places like Townsville or Cairns often depend on a single provider, and being able to show a customer whether a competitor's network is filtering a service they care about can shape contract discussions. The data produced is also useful when negotiating enterprise service agreements, because documented block histories are harder to dispute than anecdote.

Third, integration with log analysis pipelines can flag correlation events. If a corporate VPN concentrator suddenly logs spikes of failed handshakes against a specific region, pairing that signal with a probe query against the same destination can quickly tell you whether the failure is on your side or a network policy change you had no warning of.

If you operate infrastructure that spans multiple countries, the methodology generalises easily. The same automation that tracks Australian filtering can be retargeted with a different country code, and similar gap analysis techniques have been applied in unrelated industries. The kind of structured before-and-after comparison described in this drone versus helicopter gap analysis discussion mirrors how probe baselines are established before and after a suspected filter event. The pattern of recording a baseline, applying a change, and measuring the delta translates well to network auditing.

Choosing where to deploy your probe host shapes what you will see. Co-location in an Australian metropolitan data centre offers low-latency measurements at the cost of being inside the network you are auditing. Virtual servers based overseas give an outsider's view, but the round-trip time across the Tasman Sea or through Singapore can mask subtler filtering signatures. A balanced approach deploys at least two probes, one domestic and one offshore, so that verdicts can be compared rather than trusted blindly.

Sensible defaults help when first turning the system on. Start with fewer than one hundred targets, check each no more than once per hour, and store at least ninety days of history before deciding what to keep long term. Build simple anomaly alerts on top of that history, then revisit your target list every quarter, since the sites that matter to Australian users shift faster than the regulatory framework that filters them.