What is Realtime Monitoring?
The Realtime Monitor is a dark terminal-style live traffic console. It displays each security event as it happens, with controls to pause, resume, and clear the view. It is the ideal tool to see attacks the moment they occur and to verify that firewall configuration changes have the desired effect.
What is it useful for?
- See attacks live as they happen
- Test firewall configuration changes instantly
- Debug rules by blocking or allowing IPs on the fly
Differences from the General Traffic Log
- Realtime Monitor: Live, max 1000 events in memory, auto-refresh every 2s, quick filters, immediate actions.
- Traffic Log: Full historical database, advanced searches, export, no retention limit.
Console Controls
The console top bar offers three main controls plus a connection status indicator:
Start / Pause
Toggles reception of new events. Pausing freezes the current view without losing data. AJAX requests stop until resumed.
Clear
Removes all events from local memory and resets the statistics counters. Does not affect database logs.
Tab Visibility Auto-Pause
When you switch tabs, the monitor auto-pauses to save resources. When you return, it resumes only if it was active before switching.
How Polling Works
The monitor makes an AJAX request to the server every 2 seconds to fetch the latest events. The server returns only new events since the last query using a reference timestamp. If the request fails (timeout, network error), the system automatically retries without duplicating events. While the tab is hidden, polling stops completely.
Filters & Statistics
Statistics Counters
At the top of the console, live counters show the total events since the last screen clear:
| Counter | Meaning |
|---|---|
| Total | Sum of all events (Allowed + Blocked + Monitor + Challenge) |
| Allowed | Requests allowed by the firewall with no issues |
| Blocked | Requests blocked with 403 Forbidden status |
| Monitor | Events logged without blocking (log-only mode) |
| Challenge | Requests that are not blocked with a 403: instead, the visitor is presented with a verification challenge (CAPTCHA-style) before continuing |
Available Filters
Filters are applied instantly to events already loaded in memory. They do not require reloading data from the server. You can combine multiple filters simultaneously.
Search
Text field that searches across IP, URL, User-Agent, and Country. Ideal for quickly locating a specific event.
IP Filter
Shows only events from a specific IP. Useful for monitoring a specific attacker after identification.
URL Filter
Filters by access path (e.g., /wp-login.php, /xmlrpc.php). Shows which resources are being attacked.
Country
Dropdown with all detected countries. Filters events by origin country. Combined with Geo-Blocking it helps verify regional blocks.
HTTP Method
Filters by method: GET, POST, HEAD, PUT, DELETE, etc. POST requests are usually the most attacked (logins, forms).
Event Type
Select a specific category among the detected protections: Rate Limiting, Geo-Blocking, Bot Protection, Anti-Injection, Upload Protection, XML-RPC, HTTP/1.0, Backup, or normal traffic. Helps isolate issues by module.
Status
Filters by action taken: Allowed, Blocked, Challenge, Monitor. Useful to see only blocks or only allowed requests.
Events & Details
Event Display
Each event in the console displays as a terminal-style line. It includes a color-coded status indicator, timestamp, source IP, event type, targeted URL, country, and a button to view details. New events appear at the top with an entrance animation.
Event Details Modal
Clicking an event opens a modal with complete request information:
Network Info
- Source IP and port
- Country, region, city, and coordinates
- ISP / organization
HTTP Details
- Full URL with parameters
- HTTP method (GET/POST/etc)
- Full User-Agent
- Referer and relevant headers
Firewall Action
- Exact rule that triggered the event
- Detected payload or pattern (for injections)
- HTTP response code sent
Pagination
Events are displayed in pages of 50 events. Pagination controls appear at the bottom of the console. The maximum memory is 1000 events; when this limit is reached, the oldest events are automatically discarded as new ones arrive.
Quick IP Actions
Each event in the console includes quick-action buttons that let you take immediate measures on the source IP without leaving the monitor.
Allow
Adds the IP to the temporary whitelist. All future requests from this IP will be allowed without firewall inspection. Useful when you identify a legitimate IP that was being blocked by mistake (false positive).
Block
Adds the IP to the temporary blacklist. All future requests from this IP will be immediately blocked with 403. Useful when you see an active attack and want to stop it immediately.
Whitelist
Adds the IP to the permanent whitelist. Similar to Allow, but persists across server restarts. Stored in the database. Recommended only for permanently trusted IPs (e.g., office IP, monitoring services).
Alert Center
While Realtime Monitoring shows you traffic request by request as it happens, the Alert Center does something different: it checks, in the background and at most once an hour, a handful of very specific things that could mean your protection has stopped working without you noticing. These aren't generic warnings — each alert corresponds to a real check on the plugin's current state.
What it actually checks
| Check | Triggers if... | Severity |
|---|---|---|
| Firewall disabled | The Firewall is completely off — the site has no active protection right now | 🔴 Critical |
| Threat lists out of date | The Threat Intelligence / Tor lists haven't updated in over 26 hours (they should update hourly) — this usually means WordPress cron isn't running | 🟠 Medium |
Where to see them
The Alert Center lives on its own screen inside the SeenSecure panel, with an inbox similar to an email list: you can mark each alert as read, dismiss it individually, or mark them all as read at once. It doesn't duplicate notices: if an unread alert of the same type already exists, a new one isn't created until the previous one is resolved or dismissed.
Tips & Performance
Performance
The Realtime Monitor is designed to be lightweight:
- Memory limit: Maximum 1000 events in browser RAM. When the limit is reached, the oldest are automatically discarded. This prevents the browser from consuming too much memory on long sessions.
- Efficient polling: Only new events since the last query are transferred. Each typical response is under 5 KB.
- Auto-pause: Polling stops completely when the tab is not visible, using the browser Page Visibility API. Zero background resource consumption.
When to Use Realtime Monitor
Use Realtime Monitor when:
- You are testing firewall configuration changes
- You want to see an attack live as it happens
- You need to quickly block or allow IPs
- You are debugging security rules
Use the Traffic Log when:
- You need to search the full history
- You want to export data for reports
- You need forensic analysis of a past attack
- You want to see long-term trends
Practical Tips
- Use combined filters: For example, filter by "Rate Limiting" + "Blocked" to see only rate-limit blocks, or by a specific country + "Blocked" to verify your Geo-Blocking.
- Monitor after changes: Every time you modify a firewall rule, open Realtime Monitor and watch for 1-2 minutes to confirm events are processed as expected.
- Clear the screen regularly: If you have the monitor open for long periods, use the Clear button periodically to avoid accumulating 1000 events and keep the interface responsive.
- Don't trust Allow blindly: If you allow an IP and then see suspicious activity from that same IP, review it immediately. Attackers sometimes use IPs that appear legitimate.
- Use Challenge for testing: If you are tuning the Anti-Injection Shield sensitivity, set it to Challenge mode. This way you will see in the monitor what gets blocked without affecting real users.
- Open the monitor and leave it running: During an active attack, open the monitor, set your desired filter (e.g., attacker's country), and leave it running. The tab visibility auto-pause ensures it consumes no resources when you are not looking.
🔧 Troubleshooting
I allowed or blocked an IP from the Monitor and it disappeared afterward
This is the expected behavior of the console's "Allow" and "Block" buttons: they're temporary and are lost when the server restarts. If you need an IP allowed or blocked permanently, use the "Whitelist" option instead (persists in the database) or add it directly under Firewall → IP Lists.
I got an alert from the Alert Center and I'm not sure if it's still active
No need to check manually: the Alert Center re-checks the real status every hour and automatically marks the alert as resolved as soon as the issue is gone (the Firewall is active again, or the threat lists are up to date). If you want to confirm it instantly instead of waiting for the next check, look at the Firewall or Threat Intelligence status directly.
The Realtime Monitor stopped updating
First check whether the browser tab was in the background: auto-pause stops polling completely when the tab isn't visible (to avoid using resources), and resumes on its own when you return to it. If it still isn't updating with the tab visible, use the Clear button to discard the accumulated event buffer.
Frequently Asked Questions
What's the difference between "Allow/Block" and "Whitelist" in the Monitor? Allow and Block are temporary, lost on server restart; Whitelist is permanent and stored in the database. Use Whitelist only for long-term trusted IPs.
What exactly does the Alert Center check? A specific set of checks on whether your protection is still active — for example, whether the Firewall has been disabled, or whether the threat lists have gone more than 26 hours without updating (they should update hourly, so this usually means WordPress cron isn't running).
When do I use the Realtime Monitor versus the Traffic Log? The Realtime Monitor is for seeing what's happening right now and reacting instantly; the Traffic Log is for searching the full history, exporting data, or doing forensic analysis on something that already happened.
Does keeping the Monitor open all day use a lot of resources? Very little: each request weighs under 5 KB (it only fetches new events), and polling stops entirely while the tab isn't visible.