The difference
Attended runs on a person’s machine, usually started by them. They are there while it works.
Unattended runs on a server, on a schedule, with nobody watching.
It sounds like a deployment detail. It is not — it changes what the automation has to handle.
Why attended is easier
A person is present.
If something unexpected happens, they see it. If a popup appears, they close it. If the result looks wrong, they notice before it matters.
Which means the automation can be less defensive. Not that error handling is optional — but the consequences of missing a case are smaller, because somebody is watching.
Good for:
Work a person triggers. They received a batch and want it processed now.
Tasks alongside a person. Filling a form from data they have open.
Anything still being proven. Run it attended while you find out where it breaks.
Anything needing a decision partway. A person can answer a question the automation cannot.
Why unattended demands more
Nobody is there.
Four things become essential rather than nice to have:
Error handling that works alone. No person to close a dialog or retry manually.
Logging detailed enough to explain a failure the next morning. The log is all anyone will have.
Errors that surface. A job that swallowed an error and exited successfully is worse than one that failed — it records a false success and nobody is alerted.
Alerts that reach a person. Including when the job did not run at all, which produces no error.
FIGURE 1: WHAT EACH ONE DEMANDS
Attended
- A person sees what happens
- Popups can be handled manually
- Errors are noticed immediately
- Good for proving a process
Unattended
- Nobody watching
- Every case must be handled in code
- Failures must alert somebody
- Needs detailed logging
The failure that only affects unattended
The job that did not run.
An attended automation not running is obvious — the person clicked and nothing happened.
An unattended one produces nothing at all. No error, no log entry, no alert. Silence.
And silence looks exactly like success to anyone not checking.
Two things to set up:
Monitor for the absence. Alert if a scheduled job has not reported by an expected time.
Log successful runs too, not just failures. A gap in the success log is visible; nothing at all is not.
Machine and environment
Attended runs on a person’s desktop. It shares the machine with them, which means it can be affected by what else they are doing — and it only runs when their machine is on.
Unattended runs on a dedicated machine or server. It needs:
To stay available. Powered on, connected, logged in as required.
Credentials that survive. A dedicated service account, not a person’s login that expires or gets locked.
A defined schedule, and a rule for what happens if a run overlaps the previous one.
That last one catches people. A job scheduled hourly that sometimes takes ninety minutes will eventually run twice at once. Decide whether that is safe.
FIGURE 2: WHAT UNATTENDED NEEDS THAT ATTENDED DOES NOT
Monitoring for silence
- A job that did not run produces no error at all.
A dedicated service account
- Not a person’s login. It must survive them leaving.
An overlap rule
- What happens when a run starts while the last is still going.
Logging that explains
- It failed at 3am. The log is all anyone will have.
Moving from attended to unattended
The right progression, and worth doing deliberately.
1. Build it attended. A person triggers it and watches.
2. Run it that way for a few weeks. You will find cases you did not anticipate — that is the point.
3. Strengthen the error handling based on what you found.
4. Add logging and alerting.
5. Move to unattended, and watch the first runs closely.
6. Add monitoring for silence.
Skipping to unattended means discovering the exceptions with nobody watching, which is how weeks of missing data happen.
Choosing for a given task
Attended when:
The person is there anyway, triggering it as part of their work.
The volume is low.
A decision may be needed partway.
You are still proving the process.
Unattended when:
It runs on a schedule, often outside working hours.
Nobody needs to be involved.
It runs often enough that manual triggering is a burden.
The process is stable and proven.
FIGURE 3: THE PROGRESSION
Build attended
- A person triggers and watches
Run for weeks
- Find the cases you did not anticipate
Strengthen and instrument
- Error handling, logging, alerts
Then unattended
- With monitoring for silence
Licensing
Unattended robots are typically licensed differently from attended ones, and usually cost more.
Which is a real consideration when deciding how many automations to run unattended.
Pricing changes, so get current figures from the vendor rather than any article.
A practical note: several automations can often share an unattended robot if their schedules do not overlap. Worth planning schedules with that in mind.
The short version
Attended means a person is there. Lower risk, less defensive coding needed, and the right place to start.
Unattended means nobody is. Every case must be handled, logging must explain a failure the next morning, and alerts must reach somebody.
Monitor for silence, not just errors. A scheduled job that did not run produces nothing at all — and nothing looks exactly like success.
Build attended, prove it, then move.
Automation running overnight with nobody watching?
Get in touch. We set up the alerting that catches the failure nobody sees — including the job that simply did not start.
