Under the hood
How myNetWorking works
What happens under the hood: a single check, telling a service outage apart from trouble with your connection, running in the background, data and releases.
A single check
myNetWorking opens a TCP connection to the service’s host and port. If the port accepts the connection, the service is up — the app closes the connection immediately and sends no data. It is not a ping or an HTTP request, only the connection itself.
Response time is the time from starting to connect until success. For host names, it also includes the DNS lookup.
Connection timeout is 5 seconds by default. You can change it within a range of 1 to 60 seconds.
When is a service checked? Right after the app starts, and after a service is added, edited or re-enabled. After that, once the service’s Check interval has passed (30 seconds by default), and after a failed check, once the Re-check interval when down from the settings has passed (10 seconds by default).
The interval is counted from the end of the previous check. The same service is never checked twice at the same time. Throughout the check, including the verification, the service shows the “Checking…” status.
Outage verification step by step
When a connection fails, the app does not declare an outage right away. It goes through these steps:
It connects to the service. Success means the “Online” status.
After a failed attempt, it asks about the state of the connection. If the connection is not fully working, the service gets the “No network” status.
If the connection works, it connects to the service a second time, straight away. Success means “Online”.
After the second failed attempt, it checks the connection once more, from scratch. If the connection is not fully working, or if there was trouble with it in the last 30 seconds, the service gets the “No network” status.
If the host name could not be resolved on the second attempt, and the same name did resolve before, DNS is to blame — the “No network” status.
In every other case, the service gets the “DOWN” status.
Only “DOWN” opens an incident and sets off an alarm. “No network” means a problem on your side: the app records it in the log but does not blame the service.
Reference servers and quorum
The app assesses the connection by connecting in parallel to the reference servers — by default to port 53 on 1.1.1.1, 8.8.8.8 and 9.9.9.9. This is the same kind of TCP connection attempt as for services, with the same timeout. The app sends them no DNS queries.
A reference server is trusted once it has answered at least once since the app started (the current attempt counts too). The verdict depends on the trusted servers:
| Verdict | When | What it means for services |
|---|---|---|
| connection works | all trusted servers answered | a service that does not answer can get the “DOWN” status |
| connection unstable | some trusted servers answered and some did not | “No network” — no service is blamed |
| no connection | no trusted server answered | “No network” |
A few more rules:
No network connection — airplane mode or an unplugged cable — is recognized immediately, without waiting for timeouts.
One shared verdict. All services use the same verdict, which is valid for 3 seconds. Two services that stop answering in the same second therefore can’t get conflicting results.
A 30-second grace period. Every “unstable” or “no connection” verdict starts a 30-second period during which failing services get the “No network” status instead of “DOWN”.
An “unstable” verdict is only possible once a server that answered earlier stops answering. The first verdict after the app starts is therefore “connection works” as soon as one server answers.
Example: unstable Wi-Fi and a real outage
An example with the default settings: a NAS at 192.168.1.50:445, checked every 30 seconds, every 10 seconds during an outage, with a 5-second timeout. Since the app started, all three reference servers have already answered at least once (e.g. during an earlier failed check), so all of them are trusted.
| Time | What happens | Result |
|---|---|---|
| 10:00:00 | The NAS answers in 4 ms | “Online” |
| 10:00:30 | The Wi-Fi drops packets and the NAS does not answer. Servers 1.1.1.1 and 9.9.9.9 answer, 8.8.8.8 does not | connection unstable: “No network”, a log entry, no incident and no alarm |
| 10:00:50 | The NAS is still silent. All the servers answer again, but 30 seconds have not yet passed since the connection trouble | still “No network” |
| 10:01:10 | The Wi-Fi is back to normal and the NAS answers | “Online” |
| 10:30:00 | Someone turns off file sharing on the NAS: port 445 refuses the connection immediately. The second attempt fails too, and all the reference servers answer before and after it | “DOWN”: an incident, a log entry, a notification with sound and an alarm repeated every 60 seconds |
| 10:30:10 onward | The NAS is checked every 10 seconds | still “DOWN” |
| 10:42:10 | File sharing works again and the NAS answers | “Online”: the incident is closed with a duration of 12m 10s, plus a log entry and a recovery notification |
In version 1.0.0, at 10:00:30 an answer from a single reference server would have been enough to consider the connection working — and the NAS would have got a false “DOWN”.
How quickly an outage shows up
A refused connection (the host is up, but the service on the port is stopped) is detected almost instantly — “DOWN” appears in the same check.
A host that does not answer at all can take about four timeouts within one check, which is up to roughly 20 seconds: the first attempt, the connection verdict, the second attempt and the second verdict.
The worst case from the start of an outage to the “DOWN” status is therefore the check interval plus about 20 seconds — roughly 50 seconds with the default settings.
Within 30 seconds of connection trouble, a real outage is reported at the first check after that time has passed.
Watching the Internet itself
Independently of your services, the app can watch the Internet connection itself. You turn this on in Settings → Internet connection: one switch gives you a separate notification and log entry, the other records every outage as an incident. When either of them is on, the connection is checked every 30 seconds, and every 10 seconds during an outage. An “unstable” verdict counts neither as an outage nor as a recovery. The Internet check chapter has the details.
Running in the background
Monitoring runs on your device, without a cloud server. When the app is not running or the device is off, nothing is checked.
macOS, Windows, Linux: the app monitors as long as it is running. On macOS and Windows, closing the window hides the app in the menu bar or the system tray; on Linux, it minimizes the window. Only the Quit command ends monitoring.
Android: monitoring is kept running by a foreground service with the permanent “myNetWorking is monitoring” notification. Since version 1.1.0 it is a special-use service (
specialUse), which is not subject to the 6-hour daily limit that Android 15 places on data sync services. It runs as long as at least one service has monitoring enabled. After the phone restarts, you need to open the app once.iPhone and iPad: full monitoring works only while the app is open, because iOS stops its timers in the background. The app asks the system for a background refresh task no more often than every 15 minutes, but iOS decides whether and when to run it. In such a round, each enabled service is checked once, with full verification, and changes go into the incidents, the log and notifications.
More in the Running in the background chapter.
Where your data is stored
The service list, settings, incidents, log and latest statuses are saved as JSON data in the system’s settings store — only on your device. The app keeps up to 300 incidents and 500 log entries; the oldest ones are removed automatically. There are no accounts and no sync, and the app itself makes no copies in the cloud — the data can only end up in a device backup if one is turned on in the system. You’ll find the exact paths on the Installation page.
Privacy by design
This is the complete list of connections the app makes:
TCP connection attempts to each enabled service, closed immediately, with no data transferred.
DNS lookups of your services’ host names — through the operating system.
TCP connection attempts to the reference servers — only when a service check fails, or regularly while the Internet connection watch is on: every 30 seconds, and during an Internet outage every 10 seconds (the default value of the Re-check interval when down setting).
Only in versions downloaded from nci.pl, and only when you click Check for updates: one HTTPS request for a file with the latest version number.
The app has no analytics, telemetry, crash reports or ads. Notifications are generated locally. Just keep in mind that the operators of the monitored hosts and of the reference servers can see connection attempts from your IP address — as with any connection.
How releases are built
All versions are built from a single source code base (Flutter).
Stores: the Mac App Store, App Store, Microsoft Store and Google Play versions go through the store’s review; the store signs them with its own certificate, distributes them and updates them.
macOS, .dmg file: the app is signed with a Developer ID certificate, runs in the system sandbox and is notarized by Apple. Gatekeeper therefore recognizes it as checked and only asks whether you want to open an app downloaded from the Internet.
Linux: the
.deband.rpmpackages for x64 and ARM64 are built automatically by a continuous integration service. Before release, they are installed on clean systems and given a test run.We publish SHA-256 checksums next to the downloadable files.
The versions from this site differ from the store versions only in the Check for updates button and in the section of the privacy information that describes it.