Events and activity
How InfraFence events are organized - categories, severities, the incident analysis, and the Activity page that lists every action AutoMode, emergency mode and you applied, with undo.
Last updated:
Events
Everything the agent detects is an event, with a type, a severity (info, warning or critical), a time, and the source address when there is one. Events are grouped in categories:
| Category | What it covers |
|---|---|
| Web attacks | Attacks against your web server: SQL injection, XSS, path traversal, malicious bots and scanners. |
| Egress and DNS | Outbound connections to known-malicious addresses, suspicious DNS activity. |
| Malware | Malware scans, quarantined files, YARA detections. |
| File integrity | Changes to critical system files. |
| SSH sessions | SSH logins, session risk scores, SSH brute-force attempts. |
| Host monitors | Port scans, request floods and zombie processes on the server itself. |
| Infrastructure | Firewall (CSF), Kubernetes, hosting panel and exposed-database events. |
| Other | Events that fit no other category yet. |
Operational events (scans starting and finishing, updates, firewall self-repair) are kept too, but they are not counted as detections and never trigger alerts.
Event history: 30 days on Starter, 90 days on the paid plans.
Incidents and analysis
Related events become an incident. Every plan gets the instant analysis: cause, risk and what to do, computed in the dashboard from the event data, with no data sent anywhere.
On Pro and higher, Analyze with AI adds an AI analysis: likely cause, risk assessment and recommended actions, with Safe fixes you can apply in one click. It sends the incident details to a third-party AI provider, and the dashboard says so each time before you send.
Open and resolved problems
Some events describe a problem that can still be there: a database port open to the internet (db_exposed), a changed system file, a risky PHP setting, a malware finding, a failed virtual patch or hardening fix. Such a problem is Open until it is resolved. Then it shows a green Resolved badge with how, by whom and when, and it no longer counts in the critical events, in Needs attention or in the server's critical count. The events stay in the history.
InfraFence resolves a problem by itself when:
| What happened | What it resolves |
|---|---|
| The firewall closed the port, asked by you or by AutoMode | the exposed port |
| A hardening or PHP fix was applied and kept | that check |
| A later hardening scan reports the check as passed | that check |
| The file was quarantined, or you ignored the finding | that malware finding |
| A virtual patch was applied after failing | that patch |
Owners and admins can also open the incident, or the event on the server page, and choose Mark as resolved (you fixed it) or Mark as expected (the change was yours), with an optional note, and Reopen it later. Members see the state but cannot change it. Each change is recorded in the activity log.
The analysis of a resolved incident starts with the resolution, for example "port 3306 closed (AutoMode). Nothing to do now.", and keeps the original analysis under Original analysis. Reopen brings back the normal view.
A new occurrence after the resolution, such as the same port found open again, is open again. At each sync the server's agent receives the resolutions of the last 30 days, with "user", "AutoMode" or "agent" as the author and never an email address.
On the server, with agent 1.0.34 or later, the agent and the panel plugins show the same state: infrafence-agent panel events and panel findings mark each problem open or resolved, and the WHM plugin no longer counts the resolved ones. The agent also resolves on its own what it fixed: a port its firewall closed (not while the port is still reachable over IPv6), a fix applied and verified, a file quarantined, a package updated. It keeps these resolutions for 30 days, across restarts. And a database port that the agent's firewall keeps closed is no longer reported as exposed when the agent restarts, even though the database still listens on all addresses.
Activity
Activity lists everything AutoMode, the emergency mode and the fixes you applied from the analysis did, newest first. Filter by source (AutoMode, Emergency, Applied by you), by status and by emergency session. The page refreshes every 30 seconds.
| Status | Meaning |
|---|---|
| Queued | Waiting for the server to pick it up. |
| Applied | Done and verified. |
| Failed | Could not be done; the reason is shown. |
| Rolled back | Done, then undone by the agent because SSH or a site stopped answering. |
| Undone | Undone by a person. |
| Skipped | Not done, with the reason (for example monitor mode, or an address on your whitelist). |
| Awaiting approval | Waiting for an owner or admin. |
| Expired | Nobody approved it within 24 hours. |
Undo puts things back as they were; the server applies it within a minute. Installed updates cannot be undone.
Who changed what
The Activity log under Settings lists who changed what in the organization, newest first. Agent activity is not listed there.