When maintaining FortiGate devices on a daily basis, what I do most often is not change configurations, but first check the current device status. For example, if someone at a remote site reports that the network has become slow, or if a WAN link has just experienced a fluctuation, I usually do not immediately start changing configurations. Instead, I first take a look at the current state of the device.
Is the device online? Is the WAN link healthy? Is there anything unusual in the upstream or downstream traffic? Have any interfaces gone down? How are CPU and memory utilization looking? Has the Session count changed significantly compared with normal levels? In most cases, after checking these basic indicators, I already have a fairly good idea of where to look next.
The FortiGate management console can provide all of this information. But sometimes I am not trying to change configuration parameters, nor do I need to enter the full management workflow right away. I simply want to get a quick understanding of the device’s current operating status.
NOC for FGT started from this very specific need.
Being Able to Log In Does Not Mean You Understand the Device Status
FortiGate’s Web GUI is very comprehensive. System status, interfaces, routing, VPN, firewall policies, logs, and various security features can all be managed from within it.
If I need to modify policies, check routing, or adjust configurations, opening the full management interface makes perfect sense. But if someone simply tells me, “Something seems wrong with the network at this site,” the first step is usually not to change anything. Instead, I first check a few basic indicators such as CPU, Memory, WAN, Interface, and Session status.
These indicators may be basic, but they often determine the direction of the troubleshooting process. If the WAN link is already down, the problem may not be related to the firewall policy at all. If the interfaces look normal but CPU utilization or Session counts suddenly change significantly, then device load and current traffic should be investigated further. If none of these indicators show anything unusual, I can then gradually expand the scope of troubleshooting to DNS, the upstream network, clients, or the applications themselves.
For this reason, the first step in many network troubleshooting situations is not changing configurations, but observing the current operating state of the device. I first try to understand what is happening, and then decide whether I need to move on to the CLI, review logs, or inspect specific configurations.
This is also where I started thinking about the information density of NOC for FGT.
FortiManager, FortiAnalyzer, and NMS Platforms Already Exist. Why Another Tool?
FortiManager, FortiAnalyzer, as well as systems such as Zabbix, PRTG, Prometheus, and Grafana, all have clearly defined purposes and solve network management problems at different scales and levels.
If you need to manage a large number of FortiGate devices, centrally configure policies, retain logs over the long term, analyze historical trends, or build a complete monitoring system for an entire infrastructure, these platforms are clearly more suitable. I have no intention of building another NMS, nor did I design NOC for FGT as a smaller version of FortiManager.
The problem I actually want to solve is much smaller than the problems those platforms are designed to address: I simply want to quickly check how a particular FortiGate is doing right now.
A complete management platform is concerned with the question, “How should the entire network be managed?” In day-to-day operations, however, sometimes I only need to answer a much more specific question: “Is there anything about this particular device that needs my attention right now?”
Both needs fall under network management, but their usage scenarios are different.
For large enterprise environments, centralized management and monitoring platforms remain essential. But for small environments with only one or two FortiGate devices, labs, Homelabs, or temporary troubleshooting scenarios, deploying and maintaining an entire management or monitoring infrastructure just to quickly check device status can sometimes introduce more complexity than the requirement itself. The original concept of NOC for FGT also positioned it as a “lightweight FortiGate monitoring assistant,” and made it clear that it is not intended to replace FortiManager or an enterprise-grade NMS.
That is why NOC for FGT was never designed around the idea of becoming a “large platform.”
Why I Keep It Read-Only
When designing NOC for FGT, I have always wanted it to maintain a very clear position: it is first and foremost a monitoring tool, not a configuration tool.
Network device configurations are often directly tied to real production environments. Whether it is a firewall policy, a routing change, or an interface adjustment, a mistake can affect normal network operations. For a tool whose primary purpose is to quickly check device status, adding a large number of configuration capabilities would not only increase complexity, but also introduce additional operational risk.
For that reason, NOC for FGT focuses on viewing status information and assisting with diagnosis. Its goal is to help users understand the current operating condition of a device more quickly, rather than take over complete network configuration and management tasks.
This is not simply a matter of leaving out features. It is a deliberate product boundary. If the purpose of a tool is to help administrators quickly determine whether a device is operating normally, then the first priority should be to make the current state easy to understand, rather than continuously adding management features that are not part of the core use case.
Keeping the tool read-only also allows NOC for FGT to stay focused on the original problem:
Understanding the current state of a FortiGate in a simpler and more direct way.
Why Connect Directly to FortiGate?
Another design decision I made fairly early was to avoid introducing unnecessary intermediate infrastructure.
The topology of NOC for FGT is straightforward:
The app communicates directly with the user’s own FortiGate. It does not require an additional cloud server, database, Agent, or intermediate monitoring node. Device connection information is stored securely on the local device, which was also an important consideration when I chose this architecture. This is how I put the Local-First approach into practice.
If users simply want to view the current status of their own devices, there is no need to introduce an additional backend system just to accomplish that. Fewer components mean lower deployment and maintenance costs, and the overall workflow becomes more direct.
Of course, this design also involves trade-offs. NOC for FGT does not attempt to provide centralized data storage, long-term log analysis, or large-scale cross-organization device management in the way a full monitoring platform would.
But that is exactly the experience I want to preserve: open the tool, then look directly at your own device.
How Are Credentials Stored?
Since NOC for FGT connects directly to FortiGate, how device credentials are stored is something I care about as well.
Currently, device data remains on the local device. It is not synchronized to the cloud and is not uploaded to third-party services. Passwords used to log in to FortiGate are stored in the iOS Keychain using encrypted system storage, rather than being saved directly in the application’s ordinary data storage.
When access to the relevant credentials is required, NOC for FGT also supports Face ID authentication. This preserves the convenience of quickly checking device status from a mobile device without weakening the protection of locally stored credentials.
To me, Local-First means more than simply “no cloud server.” It also reflects a more fundamental principle: device information and login credentials should remain on the user’s own device whenever possible and be protected by the security mechanisms provided by the operating system.
CPU Is at 70%. Now What?
There is another issue that is easy to overlook when building a monitoring tool: displaying data does not necessarily mean helping users understand the state of a device.
For example, suppose CPU utilization is 70%. Looking at that number alone makes it difficult to determine whether a FortiGate is actually experiencing a problem. If the device normally operates at around this level, 70% may be perfectly normal. But if CPU utilization had consistently stayed around 20% and then climbed steadily to 70% over the past hour, that change would be worth investigating.
The same applies to Session counts. 10,000 Sessions may already be very high for some devices, while for other models and workloads it may simply represent normal traffic.
I gradually realized that a more important question than “How much data can the tool display?” is: Can this data actually help administrators understand the current state of the device?
At the moment, NOC for FGT primarily focuses on CPU, Memory, Session, WAN, Interface, and other basic system information. If I continue expanding its capabilities, I would rather focus on trends and diagnostics than simply add more and more numbers to the interface.
A genuinely useful monitoring tool should not merely tell the user, “CPU is currently at 70%.” It should gradually help the user determine whether “70%” is actually something worth paying attention to in the current environment.
NOC for FGT continues to focus on a much more specific problem:
When needed, help me understand the current state of a FortiGate more quickly.
Knowing what not to build is just as important for a lightweight tool as deciding what to build. Only by keeping its scope under control can the product remain simple and direct over the long term.
From “Viewing Status” to “Assisting with Diagnosis”
Looking back, I did not create NOC for FGT because FortiGate lacks management capabilities. Quite the opposite: FortiGate already has a very complete management interface and a mature enterprise ecosystem.
What actually pushed me to start building this tool was another need I repeatedly encountered in day-to-day operations: not every time I open a device am I trying to change its configuration.
Often, all we receive is a simple report such as, “Something seems wrong with the network.” From there, we need to quickly determine whether the device is healthy, whether the WAN is online, whether any interfaces are behaving abnormally, or whether system resources have suddenly changed. This information does not directly solve the problem, but it helps us quickly decide what to investigate next.
If deeper troubleshooting is required, I will still use the FortiGate Web GUI, CLI, logs, or other professional platforms. NOC for FGT is not intended to replace them.
I would rather have it serve as an observation point at the beginning of the troubleshooting process.
When all I want to know is:
“What is happening with this FortiGate right now?”
I should be able to get a basic assessment without first entering a complete and complex management workflow.
To me, that is the problem NOC for FGT was originally created to solve, and it is also why I want to keep it simple.
Try NOC for FGT
If you also want a quicker way to check the current status of your FortiGate, NOC for FGT is available on the App Store.
