A scan answers a simple question: what is listening, and what is it. You get the open ports, the service behind each one, and the raw data collected from it. You decide what that means, because you have the evidence rather than somebody else's score.
That raw data is the point. Most of what people do with Efflux starts here.
Make sure something is still up
If a service has to stay reachable, you want to know the moment it stops answering. Scan the host on a schedule and every run records the port, the service, and the response. The interesting run is the one where the port goes quiet.
This is a different question than "is the website loading." You are checking the specific port, from outside your network, the same way anyone else would reach it.
Find what you did not mean to leave open
The reverse is just as useful, and it is usually how a surprise shows up. A deploy opens a port that was supposed to stay internal. A new appliance arrives with an admin interface on a high port. A service moves and the old listener never goes away.
Scan your own ranges and you see those as they appear, rather than when someone else finds them. Add fingerprinting and you also learn what the service claims to be, which is often the part that changes your plan.
Go deeper when something looks interesting
A scan can do more than knock on the port. Turn on checks to test for known vulnerabilities, narrow those to a severity range, or ask for specific CVEs. When Efflux recognizes the protocol, a collector pulls structured detail back with it, for industrial protocols like Modbus and EtherNet/IP as well as everyday ones like SSH, SNMP, and RDP.
You can also point a scan at domains, URLs, or paths instead of ports when the thing you care about is HTTP.
Where to go next
Scans covers the request fields, the targets you can combine, and how to read results. Schedules is how you stop running them by hand.