Server monitoring asks whether a machine is up. Agent monitoring has to ask something harder: whether the agent did its job, and whether the job it did was any good. Those are different questions, and the second one is why a green uptime dashboard can sit above an agent that has been useless for a week.
Five things: that the process is alive, that each scheduled run actually fired, that runs finish rather than hang, what each run cost, and whether the output still passes a sanity check. Uptime alone is not enough, because an agent can be perfectly alive and quietly doing nothing useful.
Signals
Liveness, runs, duration, cost, output
Not sufficient
Uptime monitoring on its own
Best single signal
A recorded run, including empty ones
Cheapest alarm
Expected a run, did not get one
The five signals
Signal
What it catches
What it misses
Liveness
Crashes and crash loops
An alive agent doing nothing
Run records
Schedules that never fired
Runs that fired and were wrong
Duration
Retry loops, before the bill
Fast, cheap, wrong answers
Cost per run
Runaway spend
Correctness
Output sanity
Quality drift
Nothing, but needs a human
Why uptime monitoring is not agent monitoring
An uptime check answers one question: does this thing respond. An agent can respond to every health check while its model key is dead, its scheduled task never fires, and its output has been an apology for three days. Green dashboard, useless agent.
Uptime tells you the process exists, not that it worked.
Output volume tells you nothing on its own, because quiet days are legitimate.
The gap between those two is where every silent failure lives.
Signal 1: liveness
The floor, not the ceiling. Is the process running, and if it restarted, how often? A process that restarts once a week is fine. One that restarts every ninety seconds is in a crash loop and is probably burning money on partial runs.
Signal 2: run records, including the empty ones
The most valuable signal in agent monitoring, and the one most setups lack. Record every scheduled invocation, whether or not it produced anything. This converts silence from ambiguous to diagnostic: no record means the schedule did not fire, while a record with no output means the agent ran and correctly found nothing.
No record: the schedule is broken, or the host was asleep.
Record, no output: working as intended on a quiet day.
Record, error: something concrete to read.
Signal 3: duration
Run time is an early warning that arrives before failure. An agent that normally takes forty seconds and now takes nine minutes is retrying something, or looping. It has not failed yet, and it is about to, usually expensively.
Signal 4: cost per run
Token spend per run is the metric that catches the failure mode nobody plans for: an agent that is technically working and economically broken. A retry loop, a context window that grows every run, or a tool returning huge payloads all show up here first.
Watch cost per run, not just the monthly total, because the total hides a step change until the month ends.
A hard cap that stops execution is worth more than an alert that arrives after the money is gone.
Signal 5: output sanity
The one you cannot fully automate, and the one that matters most. Somebody has to notice that the daily brief has been summarising the same three articles all week, or that the triage agent stopped flagging anything as urgent. A weekly two-minute skim by a human beats an elaborate evaluation harness that nobody maintains.
How Qoren covers this
Environments are health-monitored with alerts, every job records live progress and a result, activity and usage are visible per agent, and the credit balance carries a hard stop rather than a warning. The fifth signal, whether the output is any good, stays with you, because it is a judgment about your work.
Normal monitoring assumes a failure is visible: an error rate, a timeout, a 500. An agent's worst failures are valid-looking. It can run successfully, cost money, and produce a confidently wrong answer, and no infrastructure metric will flag it. So agent monitoring adds cost and output quality to the usual liveness and latency.
Run OpenClaw or Hermes without managing infrastructure.
Deploy a managed agent environment, configure the runtime, and keep the agent online without Docker, VPS setup, or server maintenance.