Agents

Agents are what actually does the work. Every discovery and every scan is a job that one of your deployed agents claims and runs inside your own environment. If the fleet is unhealthy, nothing else in Argus is current, which makes this page the first place to look when a number seems stale.

This page covers running a fleet. Getting an agent deployed in the first place is a separate, one-time job covered in Deploy the agent.

Two tabs: Agents (the fleet) and Jobs (the work queue).

The fleet strip

Total Agents, Online, Offline > 1h, and Total Jobs 24h with a trend sparkline and a 7-day total.

Offline is counted at over an hour rather than instantly on purpose: agents restart, tasks get rescheduled, and a momentary gap is not an incident. A count above zero here has lasted long enough to be real.

Agent statuses

Seven of them, and the distinctions carry real operational meaning.

Status	Meaning	What to do
Online	Heartbeating and working	Nothing
Idle	Heartbeating, no work to do	Nothing. This is healthy
Stalled	Heartbeating, but its work loop is wedged	Investigate. See below
Offline	Enabled but not heartbeating	Check the task or host
Awaiting	A provisional row created when a token was issued; no agent has connected yet	Finish the deploy
Replaced	A tombstone from the conflict-replace flow. Hidden by default	Nothing
Disabled	Deliberately turned off, or auto-disabled after going stale. Hidden by default	Re-enable when ready

Stalled is the status to actually worry about

A stalled agent is heartbeating but not claiming jobs. It looks alive to every naive health check, its container is running, its logs may be quiet, and yet no work is getting done.

This status exists because that was the genuine failure mode: an agent that appeared online while silently scanning nothing, so the fleet looked healthy and your findings just quietly stopped being current. Argus separates it from Idle (healthy, nothing to do) and from Offline (plainly unreachable) so you can tell “fine”, “gone”, and “broken but pretending” apart at a glance.

If you see Stalled, restart the agent and check the job queue for work that never got claimed.

Two more distinctions worth internalising. Idle is not a problem: an agent with no queued work is supposed to sit there. And Disabled is not Offline: disabled means someone turned it off (or Argus did, after it went stale), while offline means it is enabled and should be reporting but is not. Conflating them sends you debugging a healthy container.

Replaced and Disabled rows are hidden from the default view. Bring them back with the Status filter, or the Show replaced option. Rows that are on their way out show a “hidden in Nh” countdown, so a row disappearing later is never a surprise: a disabled agent recedes after a grace period from when it was disabled, and an idle burst agent from when it was last seen.

Reading the fleet table

Column	Notes
Agent	Name, plus a version-lag badge when it applies
Status	As above
Cloud account	Which account it serves
Type	Bootstrap (enrolled itself with a token) or Manual (created by hand)
Pool	Baseline (always on) or Burst (scaled up under load)
Source	The deployment shape it came from
Jobs (24h)	Throughput
CPU, Mem	Resource use
Success 24h	The health number that matters most
Last seen	Last heartbeat

Success 24h next to Jobs 24h is the real health read. An agent running hundreds of jobs at a 60% success rate is a worse problem than one that is briefly offline, because it is producing partial results that look like complete ones.

Burst agents behave differently from baseline ones by design: they appear under load, go quiet afterwards, and then recede from the view. A burst agent sitting idle is not a fault.

Version lag

Where an agent is behind, a badge sits next to its name:

Badge	Meaning
Update recommended	Behind the recommended version. Works, but you are missing fixes
Below minimum	Behind the minimum supported version

Treat Below minimum as urgent: it means the agent is older than what the platform expects to interoperate with. Updating is covered in Updating the agent.

Row actions

Action	Effect
Show deploy snippet	Re-opens the deploy instructions for this agent
Rotate API Key	Issues a new key with a grace window (below)
Disable / Enable Agent	Stops or resumes work without touching the deployment
Delete Agent	Removes the agent record

Disabling an agent needs no restart, and does not kill running jobs

Disable takes effect on the agent’s next poll, which returns a 403 and drops it into an idle retry loop. It keeps retrying, so re-enabling here brings it back on the next retry cycle with no redeploy, no restart, and no shell access.

In-flight jobs continue to completion. Disable is a “stop taking new work” switch, not a kill switch, so you will not corrupt a scan that is halfway through by disabling its agent.

This makes Disable the right tool for pausing an agent during a maintenance window, and much safer than tearing down the task.

Key rotation and its grace window

Rotating an agent’s API key issues a new one while the old key stays valid for a grace period, then stops working.

That overlap is the whole point: it means rotation is not an outage. You rotate, update the agent’s configuration during the window, and the agent keeps working throughout. If you rotated with no grace, every agent would break the moment you clicked the button and stay broken until you got to it.

The window resolves from a per-agent override, falling back to the tenant default. The drawer’s Key rotation section shows the resolved value and badges whether it is an override or inherited. Your tenant may disable per-agent overrides entirely by policy, in which case the section says so and points you at Settings.

A rotated key is displayed once. Copy it immediately; there is no way to retrieve it later, only to rotate again.

Enrollment tokens are a separate credential from agent API keys, and they live on the cloud account rather than the agent. See Cloud Accounts and Credentials: Bootstrap vs Manual.

The agent detail drawer

Overview carries status, cloud account, total lifetime jobs, 24-hour success rate and average duration, jobs in flight, CPU, memory, last seen, and source.

Identity holds the name and its labels. Labels drive job routing: an agent whose labels match a job’s affinity is preferred for it, using keys like region, account, and supports. This is how you steer particular work to particular agents rather than letting any agent claim anything.

Runtime config exposes per-agent overrides for log level, concurrent jobs, poll interval, heartbeat interval, CPU and memory throttle percentages, and whether to skip claiming work while over the throttle.

Runtime settings resolve in a specific order

Environment seed, then tenant default, then agent override. Worth knowing before you debug a setting that “will not stick”: a value baked into the agent’s environment at deploy time is the starting point, the tenant default applies over it, and a per-agent override wins last.

Overrides also save sparsely: a value equal to the tenant default is stored as inherited rather than pinned, so the agent keeps following the default if you later change it. That is usually what you want, and it is why a value you typed may show as “tenant default” rather than “override”.

Like key rotation, per-agent runtime overrides can be disabled by tenant policy.

The Jobs tab

Every discovery and scan job, which is where you go when a scan failed and you need the reason.

Columns: Job ID, Agent, Cloud account, Type, Status, Started, and Duration. Statuses are pending, running, completed, failed, and cancelled. Filters cover status, agent, cloud account, and job type.

A job sits pending until an agent claims it. Pending jobs piling up with no running ones is the classic symptom of a fleet problem rather than a scanning problem: check for Stalled and Offline agents first. If an agent goes silent mid-job, or a job sits unclaimed with no healthy agent to run it, the platform reaps it and marks it failed with a reason rather than leaving it stuck forever.

Deep links land here from all over the product. A datastore’s scan history, an alert’s resolving scan, and a not-found datastore’s declaring run all link to /agents?tab=jobs&jobId=<id>, and Cloud Accounts has a View jobs for this account action. Following those links is almost always faster than filtering by hand.

Adding, replacing, and removing agents

All of it is deploy-side work:

• Adding an agent, or re-deploying one: Deploy the agent, starting with Pre-flight.
• Confirming a new agent connected: Verifying connection. A new agent shows here as Awaiting until its first heartbeat lands.
• Upgrading: Updating the agent.
• Something is wrong: Troubleshooting.
• Removing an agent and its cloud resources: Teardown. Deleting the agent row here does not remove anything from your cloud account.

A daily read of this page

1. Offline > 1h above zero, or any Stalled agent: fix that first, because everything else is aging.
2. Success 24h below your normal: look at the Jobs tab for the failure reason.
3. Any Below minimum version badge: schedule an update.
4. Pending jobs with nothing running: a fleet problem, not a scan problem.