This note continues the production testing documented in IFA Trabant: Extended Production Test and Development Roadmap.
The previous test concentrated primarily on decision behaviour.
During an 87-hour production monitoring window, IFA Trabant recorded three complete autonomous failover cycles, rejected multiple ambiguous observations and subsequently restored the normal Cloudflare delivery path without human intervention.
That experiment established that the watchdog could both act when its configured threshold was reached and remain inactive when the available evidence was insufficient.
The present follow-up had a narrower purpose.
No new decision logic was introduced.
No attempt was made to optimise the monitoring node.
The objective was simply to leave the same reference hardware operating continuously again and observe whether prolonged execution produced any obvious degradation in the Linux host.
1. Test platform
The reference node remained unchanged:
Hardware: HP Stream
Installed RAM: 2 GB
Operating system: antiX Linux
Window manager: IceWM
Init system: runit
Monitoring architecture: IFA Trabant
Primary role: independent website availability monitoring and failover control
The hardware was deliberately left unchanged because the purpose of the test was not to establish minimum theoretical requirements.
The useful question was whether the already validated reference node remained operationally stable during another multi-day period.
2. Starting condition
During dedicated operation, with no modern browser or other significant interactive applications running, the complete antiX environment typically used approximately:
RAM: 250–260 MB
Swap: 0
CPU: low single-digit utilisation under normal conditions
Short WLAN bursts remained visible at intervals.
This was consistent with the watchdog model: the node spends most of its time idle, performs brief network observations, records the result and returns to an idle state.
Continuous monitoring therefore did not imply continuous computational load.
3. Extended runtime
The node was subsequently left running continuously.
At the end of the observation period, the system reported:
Uptime: approximately 4 days and 12 hours
Resolution: 1366 × 768
Init: runit
Disk usage: approximately 15.5 GB of 28.2 GB
No reboot was required during the observation period.
No operating-system instability requiring intervention was observed.
The system remained responsive at the end of the run and was terminated normally using poweroff.
This is a modest result, but it is relevant to the architecture.
IFA Trabant is intended to perform a persistent control function. A monitoring system whose own host requires frequent intervention would merely introduce another availability problem.
4. Dedicated operation versus interactive use
A useful secondary observation appeared when the same machine was used interactively.
Before opening contemporary interactive applications, memory consumption remained close to the dedicated baseline:
RAM: ~252–254 MB / 1.79 GB
Swap: 0The machine was then used to open ChatGPT, a terminal and editing tools while IFA continued operating in the background.
Resource consumption increased substantially.
A later observation showed approximately:
RAM: 687 MB / 1.79 GB
Swap: 421 MB / 1.00 GB
Disk: 15.5 GB / 28.2 GBThe machine nevertheless remained operational.
This distinction is useful.
The resource constraint did not originate in the monitoring architecture.
It appeared when a lightweight dedicated Linux node was asked simultaneously to behave as a contemporary interactive desktop.
The two workloads should not be confused.
5. Swap activity
The appearance of swap during interactive use was not treated as evidence of failure.
Linux may retain inactive memory pages in swap after the process that generated the original memory pressure has been closed.
There is therefore little value in manually forcing such pages back into physical memory merely to produce a visually cleaner system monitor.
For the purposes of IFA Trabant, the relevant comparison is simpler:
Dedicated watchdog operation:
~250–340 MB RAM
0 swap during the documented unattended periods
Interactive browser / ChatGPT / editor workload:
substantially higher RAM consumption
swap activityThe reference machine is consequently much better suited to its dedicated monitoring role than to intensive interactive desktop use.
That is not surprising.
It is nevertheless experimentally useful to observe the difference on the same hardware.
6. What this test does not prove
A four-and-a-half-day runtime is not a reliability certification.
It does not establish:
- long-term hardware reliability;
- immunity from storage failure;
- immunity from Wi-Fi or router failure;
- availability during electrical outages;
- suitability for enterprise high-availability requirements;
- equivalence to redundant monitoring infrastructure.
Nor does this particular follow-up attempt to establish the cause of any external network event.
Those questions require different tests.
The purpose of this run was considerably narrower: determine whether prolonged operation of the reference node itself introduced an obvious resource or stability problem.
None was observed.
7. Why the result matters
The result reinforces an architectural distinction already visible in the earlier experiments.
IFA Trabant does not require substantial continuous computation.
Its task consists primarily of:
observe
wait
observe
compare
decide
log
waitActual infrastructure modification is exceptional.
Most monitoring cycles should result in no action at all.
That makes the workload particularly suitable for low-resource hardware.
A modern multi-core computer would obviously perform the same operations.
It would not necessarily perform the monitoring function more correctly.
For this application, additional processing capacity has little value once the requirements of the control loop have been satisfied.
8. Legacy hardware as a control node
The experiment should not be interpreted as an argument that old computers are generally superior to modern ones.
That would confuse capability with suitability.
The HP Stream is poorly suited to many contemporary interactive workloads.
It is, however, entirely capable of running a lightweight Linux environment, executing shell utilities, performing DNS and HTTP observations, maintaining a small persistent state and invoking an external API when required.
Those capabilities are sufficient for IFA Trabant.
The relevant engineering question is therefore not:
How old is the hardware?
It is:
Does the hardware provide the resources and interfaces required by the function?
In this case, it does.
9. From endurance to replication
The previous production test established autonomous intervention and recovery. The present run provides further evidence that the reference node can remain operational for several days without requiring host-level intervention.
The next stage should therefore not add more complexity to the single-domain watchdog.
It should test replication.
Additional production domains can be assigned independent watchdog instances while sharing the same physical Linux node.
The intended structure is deliberately simple:
Physical Linux node
|
+-- Watchdog A
| independent state
| independent counters
| independent log
|
+-- Watchdog B
| independent state
| independent counters
| independent log
|
+-- Watchdog C
independent state
independent counters
independent logThe essential design principle remains:
Local failure, local response.
A failure or false positive affecting one monitored domain should not automatically alter the state of another.
10. Next test
The next production experiment will therefore move from endurance testing to multi-domain operation.
The objective will not be to build a central monitoring platform.
Each domain will retain an independent shell script and independent operational state.
This deliberately avoids a shared decision state that could propagate an incorrect observation across unrelated websites.
The question for the next experiment is simple:
Can several autonomous watchdogs share the same small Linux node while preserving operational isolation?
The hardware evidence collected so far suggests that computational capacity is unlikely to be the limiting factor.
The experiment will determine whether the same simplicity can be preserved at the architectural level.
Conclusion
IFA Trabant completed another prolonged run on the same 2 GB HP Stream reference platform.
After approximately four and a half days of continuous uptime, the Linux host remained responsive and could be shut down normally.
During dedicated operation, resource consumption remained very low.
The substantially higher memory and swap activity observed later was associated with interactive desktop workloads rather than the failover monitoring function.
The result does not demonstrate enterprise-grade reliability.
It demonstrates something narrower:
A persistent monitoring and failover control function does not necessarily require persistent computational load.
The next step is no longer to make the watchdog larger.
It is to determine whether the validated design can be replicated across several independent domains without losing the simplicity that made the original system useful.
