“The website works for us.” “Our customers cannot open it.” Different DNS answers, network routes, CDN rules or security controls can sit between those two observations. EyeballMonitor is a FalcoSoft ITS project focused on this practical investigation problem. We are introducing it as part of our own technology ecosystem and explaining what its Indiegogo campaign is intended to support.
The campaign has a €75,000 funding goal and is scheduled to launch on 27 October 2026. At publication, its page is in the pre-launch stage: visitors can select Follow for updates. Financial backing becomes available after the campaign launches. Visit EyeballMonitor on Indiegogo.
The problem behind the project
A successful availability check provides useful information about one observation point. If a server in a datacentre receives HTTP 200, that does not rule out trouble for someone using a different internet provider or DNS resolver. A server response alone also cannot show whether a browser rendered the page correctly.
Consider an online shop whose homepage opens while an external resource or security rule prevents some visitors from completing a purchase. The team needs context: where the check originated, what the website returned and what appeared in the browser. This illustrates the diagnostic question EyeballMonitor addresses. It does not mean that the product automatically exercises every step of every checkout.
What already works
According to the published project information, the working foundation includes eight agents across six countries: Bulgaria, Poland, Italy, Türkiye, the United Kingdom and Singapore. Available capabilities include availability and response-time checks, HTTP results, browser rendering, screenshots, timestamps, incident history and alerts. Desktop and mobile browser profiles are supported.
Browser profiles and physical connectivity are separate things. An iPhone or Android view does not automatically mean the check travelled through a mobile operator’s SIM connection. Eight agents likewise do not mean eight completed independent consumer or mobile connections: network types vary by location. Expanding the range of real network paths is a central reason for crowdfunding.
The official product demonstration was published on 19 October. It provides an introduction before anyone decides whether to support the project. Interested teams can also access the technical white paper through the website. Watch the demonstration or explore EyeballMonitor.
What the funding would support
Software can be deployed remotely, but presence in different real networks involves physical and operational work. Equipment needs suitable placement, power and internet connectivity. Where applicable, mobile service and local arrangements are also necessary. Installation is followed by agent health monitoring, software updates, maintenance and replacement when hardware fails.
The plan also includes browser-processing capacity, evidence storage, infrastructure reliability and security. Additional observation points are useful only when their results remain traceable and comparable. Deployment is therefore intended to proceed in stages, according to the available budget and local conditions. This article promises neither a fixed number of new devices nor automatic coverage of every operator when the campaign ends.
Where AI fits into the roadmap
Later product stages envisage bringing dependency information and different operational signals together. Websites may depend on DNS, cloud infrastructure, CDNs, payments or identity services. Putting provider status information alongside browser observations could help a team decide what to investigate next.
Automatic dependency discovery, correlation, root-cause candidates and the longer-term Incident Agent concept remain roadmap directions. They are not presented here as available features. Correlation needs validation: two simultaneous failures do not establish a causal relationship. The intended role of intelligent assistance is to work from verifiable observations with human oversight, rather than fill evidence gaps with a confident explanation.
Who could benefit
The initial practical audience includes hosting providers, developers, DevOps and infrastructure teams, SaaS platforms and online shops. For these teams, the useful question is specific: could an observation from another network shorten the work needed to reproduce and understand an incident? A screenshot shows a symptom, while the timestamp, observation point and HTTP result provide context. A final diagnosis may still require logs or further checks.
This approach can also make discussions between technical teams more concrete. Instead of comparing a general “up” result with a customer’s description, participants can examine a particular observation at a particular time. Its usefulness depends on the relevance and quality of that evidence; it is not a guarantee that every failure will be reproduced or automatically explained.
How to follow or support the campaign
Open the Indiegogo campaign, review the demonstration, project description, terms and risks. Before launch, Follow is the way to receive updates. After launch, the page will display the available backing options. Following does not create a financial commitment.
For people investigating these incidents in practice, a technical question or concrete feedback is also valuable. The aim is to expand observation across different real network paths and give teams a stronger factual starting point for investigation.
*Editorial disclosure: this article introduces our own project within the FalcoSoft ITS ecosystem. The cover was created with AI assistance and is a conceptual illustration, not a map of completed network coverage.*
