Seeing a Rapid7 agent offline in the console usually means the agent is down. In my case, the service looked like it was running, but the agent had never come up properly since the install.
I reinstalled the Rapid7 agent on a Linux server. After starting it, the logs filled with certificate errors and configuration errors. I migrated the SSL certificates and configuration files from the previous install, and those errors went away.
The service showed as running. The Rapid7 console still showed the asset as Offline.
The Logs Looked Like a Restart Loop
The logs kept showing the agent starting and stopping, over and over. Combined with an asset that never appeared in the console, that looked like a restart problem, so systemd was the first thing I checked.
I looked at the restart counter:
systemctl show ir_agent -p NRestartsIt returned NRestarts=0. systemd had never restarted the service, which ruled out the restart policy as the cause. Whatever was producing that start-and-stop pattern, it wasn’t systemd.
What Was Left
By then the picture was odd. The certificate and configuration errors were gone, and systemd wasn’t restarting anything. But looking back over the timeline, the agent process had not run properly even once since the install.
Fewer error messages had made it feel like progress. It wasn’t the same as the agent working.
The Missing Log
Next I went looking for the agent’s own log under /var/log/rapid7, expecting connection errors or something I could search on.
agent.log wasn’t there.
That told me more than an error would have. An agent that was trying to connect and failing would normally leave a trace. No log suggested it had never gotten as far as trying. Nothing indicated the agent had been initialized.
So I went back through what I had actually done: installed the package, started the agent, fixed the errors by migrating certificates and configuration. The one step I hadn’t done was running configure_agent.sh.
Why I Missed It
There was no guide that told me to run that script. What I had was the error output, so I worked from that. Certificate errors and configuration errors kept appearing, I fixed them by moving the old files over, and the errors stopped.
That felt like confirmation that the setup was complete. In reality it only confirmed that the files were right. It said nothing about whether the agent had been activated.
The Fix
I ran configure_agent.sh and brought the service up. About 30 minutes later, the asset showed up as Online in the console.
What I’d Check Next Time
systemctl status only tells you a process exists. It doesn’t tell you the agent is registered or talking to the platform. After any agent reinstall or migration, this is what I’d verify:
- The service is running and the process actually stays up. Check the logs for repeated start-and-stop lines.
- The activation step has been run, not assumed.
- The agent log exists under
/var/log/rapid7and is being written. - The asset shows Online in the console. Allow time. For me it took about 30 minutes after the script ran.
A shrinking list of errors is not on that list, and it’s the one I trusted last time.
Related reading: My earlier post on Rapid7 Insight Agent and “connection reset by peer” covers a different failure on the same agent. The Alert That Never Fired is another case where something looked healthy and wasn’t.
FAQ
Why does a Rapid7 agent show Offline when the service is running?
A running service only shows that the process was started. If activation or registration never completed, the agent can’t communicate with the platform, and the console will keep showing it as Offline.
Does migrating certificates and config files replace the activation step?
No. Copying them can make certificate and configuration errors disappear, but that doesn’t prove the agent was activated. Check the agent log and the console, not just the error output.
How long does it take for the asset to show Online after activation?
In my case, about 30 minutes after running configure_agent.sh and starting the service. Your timing may differ.