What Rapid Reaktor Logs
And Why It Matters
Every automated block is recorded in full, from the raw syslog message that triggered it to the moment the IP expires off your blocklist. Nothing happens silently.
Three Questions You Need to Answer
When a system makes automated firewall decisions, you need to be able to answer three questions at any time:
Rapid Reaktor logs the complete answer to all three, automatically, for every action it takes. No logging setup required. No external service. Just a local database on your own infrastructure that captures the full lifecycle of every block.
What Gets Recorded
Every block event is written to the triggered_actions table in Rapid Reaktor's SQLite database. Here's exactly what's captured:
| Field | What It Contains |
|---|---|
| id | Auto-incrementing event ID |
| rule_name | The rule that matched and triggered the block |
| extracted_ip | The attacker IP that was acted on |
| action_type | edl for a blocklist update, edl_expiration for a TTL removal |
| action_result | Plain-English summary of the action taken, including which EDL and TTL applied |
| syslog_message | The complete, unmodified syslog message that triggered the rule |
| triggered_at | Exact timestamp of when the action fired |
The full raw syslog message is stored. Not a parsed summary. The actual message, character for character, exactly as Rapid Reaktor received it.
What a Real Block Looks Like
This is what a real block event looks like in the database:
id 42 rule_name SSH Brute Force Block extracted_ip 185.220.101.47 action_type edl action_result Added 185.220.101.47 to blocklist-ssh (TTL: 24 hours) syslog_message Jan 15 03:42:17 fw01 sshd[2341]: Failed password for root from 185.220.101.47 port 54812 ssh2 triggered_at 2025-01-15 03:42:17
You can see exactly which rule fired, which IP was blocked, which EDL it landed on, how long it'll be blocked for, and the raw syslog line that caused all of it. That's your full audit trail in a single row.
Expiration Is Logged Too
When a blocked IP's TTL expires, Rapid Reaktor doesn't just quietly remove it. It writes a second log entry:
action_type edl_expiration action_result Removed 185.220.101.47 from blocklist-ssh triggered_at 2025-01-16 03:42:17
Every IP has two entries: when it was blocked, and when it was released. You have the complete lifecycle of every address that ever touched your blocklist.
The expiration check runs every 15 minutes in the background.
Exporting Your Logs
activity_log.csv, the full triggered_actions table, every row, every field.The CSV export is always the full table. Filtering by date, IP, or rule is available in the Activity Log UI view, but those filters don't carry over to the export. If you need a filtered export, pull the CSV and filter in Excel, or query the database directly.
Where the Data Lives
The ./data directory is volume-mounted, so the file persists on your host machine outside the container. Your log data never leaves your infrastructure.
Retention: The triggered_actions table grows indefinitely. There is no built-in pruning or rotation. Managing retention is up to you. You can delete rows directly, archive old entries, or swap in a fresh database file. Because it's SQLite, any standard database tool works.
Incident Reconstruction
You open the Activity Log and search the IP. You see:
rule_name SSH Brute Force Block extracted_ip 185.220.101.47 action_result Added 185.220.101.47 to blocklist-ssh (TTL: 24 hours) syslog_message Jan 15 03:42:17 fw01 sshd[2341]: Failed password for root from 185.220.101.47 port 54812 ssh2 triggered_at 2025-01-15 03:42:17
No digging through firewall logs. No guessing. No black box.
Two Honest Limitations
These gaps are worth knowing before you rely on the audit log for compliance or forensics.
triggered_actions.