---
title: Overseers — running one (part 2)
---

# Overseers — running one (part 2)

## What it is

This is part 2 of the [Overseers](overseers.md) page — the operating half: keeping an Overseer running and steering what it watches.

## Where to find it

The **Overseers hub** again — every control described here is on one of its tabs or in the Overseer's own settings.

## How it behaves

### How it wakes up (the check-ins)

Each Overseer is **woken automatically on its own schedule** to do the job you gave it. There is
nothing to set up — no cron job, no scheduled task, no script.

- **Two check-ins are seeded for every Overseer, and neither can be removed.** A **Heartbeat**
  every 15 minutes — the regular look around — and a **Review** every 6 hours: a slower, wider
  pass over the standing picture.
- **They are ordinary durable schedules on the Overseer's own session**, so a check-in survives
  an app restart and the session being replaced. A wake-up still arrives as a real turn, so the
  Overseer remembers what it looked at and did last time.
- **The keeper restores a check-in that goes missing or runs out.** Every schedule fires a finite
  number of times, so one that reaches the end of its budget is re-created on the next keeper
  tick — an Overseer that looks alive but is never woken again is the failure this prevents.
- **Every wake-up is also SUBMITTED, not just delivered.** The wake says only that the round is
  due: the Overseer pulls its brief (`GET /overseer/heartbeat` — the fleet digest, the board
  traffic, and the sessions it owns) and then sends the round with `POST /overseer/round`. That
  submission is what reaches the audit list, your inbox and the fleet board, so a round the
  Overseer does not send is a round nobody ever sees.
- **Change the cadence fleet-wide** in the hub's _Fleet settings_, or per Overseer on its
  Settings tab (the wizard's Rhythm step names the fleet's live default).
- **The Settings tab's _Wakes up_ section shows what is actually scheduled** — each check-in, the
  cadence it really fires on, how much of its fire budget is left, and a warning when a required
  one is missing, spent, or set to a cadence no schedule can express.
- **Add a check-in of your own** from that same section: a Heartbeat or a Review at any cadence a
  schedule can express exactly (minutes dividing an hour, or whole hours). Adding one never
  replaces or disables the required pair.
- **An Overseer can re-pace its own heartbeat**, without asking you, by calling
  `POST /overseer/heartbeat {"everyMinutes": N}`. Its briefing tells it so. That is the point: an
  Overseer that notices it is checking too often, or not often enough, simply fixes it.
- **A cadence of `0` means "never wake this one"**, and it is honoured where a check-in is
  created or restored. An explicit per-Overseer value wins in both directions, so "every
  Overseer except this one" works — a heartbeat already scheduled on a running session keeps
  firing until that session restarts or its own fire budget runs out.
- **A quiet wake-up leaves no trace.** If it wakes, looks around, and finds nothing worth doing,
  nothing is recorded — so the audit list stays readable even at a fast cadence.

**Each wake-up is a real paid turn.** Every 15 minutes is 96 a day per Overseer, before the
6-hourly review adds four more.

> **Check-ins used to be a private timer.** Until 2026-09-19 each Overseer was woken by a
> bespoke in-memory timer with its cadence in a settings number, and a round was read back out
> of the session's own transcript. Both are gone: the cadence lives on ordinary wake schedules,
> and the round is submitted by the Overseer itself. The keeper took over two jobs from the
> retired timer — restoring a required check-in, and arming the runaway-spending breaker.

Two different things guard that spending, and it is worth knowing which does what:

- **The runaway-spending breaker** is a _runaway detector_, not a spending cap — a
  permanently fast cadence simply becomes the normal it measures against. It watches for a
  sudden spike against what the Overseer normally costs, and pauses it until you restart.
- **The shared daily ceiling** IS a hard cap, and it is **off by default — there is no
  limit until you set one**. Set a dollar figure and it covers the Overseer _and every swarm it
  runs_, together, as one budget. When the day's total reaches it the Overseer stops waking and
  no new swarm workers start. It resets at local midnight and resumes on its own — unlike
  the breaker, it never needs a restart, because being out of budget for today is not a fault.

  Swarm spending counts against the ceiling but is deliberately kept OUT of the breaker: a swarm
  running several workers costs far more than an Overseer alone, so counting it into the spike
  detector would trip it every ordinary hour and leave the Overseer paused for doing its job.

Only the **global** Overseer's wake-up carries the fleet digest and weekly summary as context;
the others just get on with their own job.

**Only the global Overseer can put a card in your inbox from a wake-up.** Every Overseer records
what it did in the audit list, but a card is a stronger claim — _a person should look at this_ —
and only the global one is reading the fleet-wide digest that produces that kind of conclusion.
Without this, a fleet of Overseers each waking four times an hour would turn your inbox into an
activity log, which is the exact noise the Overseer exists to remove.

> **History worth knowing.** Until this existed, an Overseer was never woken at all. The service
> meant to do it was written, tested, and documented — but was never switched on at startup, so
> it never ran once, and a per-project or custom Overseer's job description was never executed by
> anything. The same was true of the spend breaker: it could not trip, because nothing called it.
> Both are now live.

### How it stays alive

A background service — the **keeper** — checks every 30 seconds whether a live Overseer session
exists for each enabled slot (global + any per-project ones). If none exists, it spawns a fresh
one. The keeper uses an **exponential backoff** when spawns fail and raises one inbox alert after
five consecutive failures so you know something is wrong.

The 30-second check is the keeper's _steady state_, not a delay you wait through: **switching an
Overseer on runs the keeper straight away**, so it starts within a couple of seconds of the
switch rather than at whatever tick came next.

The keeper also holds the two spend gates and restores the check-ins, both of which used to
belong to the retired wake-up timer: a **tripped runaway-spending breaker pauses the keeper**
until an app restart, a **reached shared daily ceiling skips the tick** (so it comes back by
itself when the day rolls over), and every healthy tick **re-seeds a required check-in** that has
gone missing or run out of fires.

A brand-new Overseer gets its check-ins the moment it starts — they are seeded against the new
session as it is created, so there is no first interval of silence to wait through.

**Archiving an Overseer's session switches that Overseer off.** The keeper stops replacing it, and
so the agent stops and stops costing anything, until you start it again. This is the second way to
turn one off, alongside the run switch on its Settings tab — use whichever is in front of you, and
the two agree.

To bring it back, either **reopen that session** (which clears the archive) or **switch the slot on
again**; a switch-on counts as the more recent of the two instructions, so it wins. Nothing is lost
either way — the notes file and the transcript stay exactly where they are.

The stuck-session sweeper (which recovers crashed sessions for normal agents) explicitly
**excludes** Overseer sessions. Only the keeper ever revives them. This prevents the sweeper's
hard cap (12 consecutive failures → permanent terminal state) from applying to a session that is
designed to be permanent.

### Memory and scheduled restarts

The Overseer's **durable memory** lives in a file called `NOTES.md` in the app's own data
directory (`<userData>/overseer/NOTES.md`), and it stays there for **every** kind of Overseer —
global, per-project or custom. Running one inside your repository therefore never touches that
repository: no file is created, changed or deleted in it, and its git status is exactly as you
left it. You can read the notes or add to them directly; the Overseer writes to them as it
discovers patterns worth keeping.

When the Overseer starts (whether for the first time or after a scheduled restart), its standing
instructions reach it as **a system-level briefing the session carries every turn**, never as a
file dropped into the working directory:

1. A base persona with an instruction-lock section (prompt-injection guard).
2. Your custom Overseer instructions (from settings).
3. Its own notes, read from the notes file above.

The briefing is delivered through the system prompt rather than a generated `CLAUDE.md`, which is
what makes "an Overseer writes nothing into your repo" structural instead of a promise: a
generated file in a project's folder would collide with one the project may already own, and
would dirty every repository that has an Overseer. (Upgrading from an older build deletes that
generated file once, so an existing Overseer cannot end up carrying its instructions twice.)

Notes carry forward across restarts — the Overseer never loses what it has written down. Context
resets (fresh session, no accumulated context); notes persist.

**Scheduled restarts** happen automatically at the interval you set (`overseerRestartHours`,
default 24 h). The keeper terminates the current session and immediately spawns a fresh one that
re-reads `NOTES.md`. Restarts are deferred if the session is mid-turn (status `running`,
`starting`, `stalled`, or `terminating`) — the keeper waits for the next tick. Every restart is
recorded in the action ledger (see below).

### How it screens the inbox (the hold mechanism)

When any alert is created — whichever part of the app or which agent raised it — the Overseer
can place a **hold** on it:

- The hold is a nullable `held_until` timestamp on the `inbox_alert_items` row.
- All three user-facing alert reads (`listActiveAlerts`, `listDripSourcedInboxItems`,
  `listAlertsByDrip`) **exclude held rows by default**. A held card is invisible to you, to the
  phone, and to the badge count — but it is NOT deleted or suppressed at the push layer.
- A **release sweep** runs on each cycle and clears expired holds, emitting `ALERT_CHANGED` so
  the renderer picks up the newly-visible card.
- A **clock-jump floor** force-releases any hold sitting too far in the future (a multiple of
  the hold window), so a bad clock cannot hold a card forever.
- Past a **storm ceiling** (many cards held at once), new cards are not held at all — fail-open.
- **Some cards are never held** (`overseer-never-held.ts`): anything that can page the phone
  (owner-critical alerts), auth/spend/security/data-loss/real-time-comms prefixes (including all
  team-chat notices), and any card with an empty or unknown dedupKey. An unclassifiable card is
  always immediately visible.
- If the Overseer is dead or unreachable, the hold step is skipped and the card goes straight
  through. The Overseer being broken can never silence your inbox.
- **Only the global Overseer can cause a hold**, because it is the only one that comes back to
  judge held cards. A per-project Overseer never holds anything: a card it withheld would be
  read by nobody and simply released later, which is delay without screening.
- Until 2026-09-11 this section overstated things. Holding was wired into one of the two ways
  an alert can be created, and the other one — the one almost every agent-raised card comes
  through — skipped the screening entirely. On the owner’s machine that was 130 of 138 live
  cards, and 14 cards had ever been held out of 9,910. Both ways now screen.

### Having more than one Overseer

There are three kinds, and you can run as many as you like at once.

| Kind            | What it watches                 | How you get one                                                                |
| --------------- | ------------------------------- | ------------------------------------------------------------------------------ |
| **Global**      | everything                      | on whenever the Overseer is on                                                 |
| **Per-project** | one project                     | turn on "an Overseer for every project", or switch on the one project you want |
| **Custom**      | only the sessions you assign it | you create it and give it a name                                               |

Any of the three can also be handed **specific sessions** to watch — see below.

**"An Overseer for every project"** (`overseerAutoPerProject`) gives each project its own,
without switching them on one at a time. It is **off by default** — each Overseer is a real
running session that costs money, so switching them all on is your call, never a default.

You can still turn an individual project **off** while that is on. An explicit per-project choice
always wins, in both directions, so "every project except this noisy one" works.

Each Overseer is a fully independent session: its own spawn claim, its own failure counter and
retry backoff, and **its own memory**. A slow spawn for one never delays another, and one going
down does not affect the rest.

A project-scoped alert goes to that project's Overseer if it has one, otherwise to the global one.

### Copying an Overseer

A running session can ask for a copy of itself in one call, and what it gets depends on what the
copy is FOR. `POST /session/:id/clone` takes a `kind`:

| `kind`              | What you get                                                                                                                                                           |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`one-off`**       | An ordinary session carrying the same opening mission. It runs its job and finishes — it is not an Overseer, nothing keeps it alive, and no slot is created for it.     |
| **`standing-peer`** | A full new Overseer on its own slot, with its own heartbeat and its own memory, kept alive by the keeper like any other.                                               |

**The mission is recovered, never invented.** The copy is given the mission the source session was
_started_ with — its own first message, the exact text a person typed. Hand it a session with no
opening message and the call is refused with "there is nothing to copy", because a copy carrying a
made-up job would be worse than no copy at all. An optional `job` in the body is appended _after_
that mission, never instead of it, so the copy still knows what it is before it is told what this
particular run adds.

**A standing peer does not ask you first.** Creating an Overseer normally raises an approval card
— `POST /overseer/slots` still does, and so does switching one on. This one path is a deliberate
exception to that rule: you already approved this Overseer by standing it up and giving it a
standing job, so it may make a peer of itself on its own authority. Only an Overseer can ask for
one — a plain session asking is refused — and the ordinary routes are untouched, so every other way
of creating an Overseer goes on asking exactly as before.

Nothing about that is open-ended, because two brakes stand in front of it:

- **Your cap** — `overseerSelfCloneLimit` in Fleet settings (_Copies of itself_). Leave it blank
  and there is no cap. Set a number and it bounds how many peers made _this_ way still exist, so
  deleting one frees the room back for another. It is one number for the whole box, and a
  switched-off peer still counts — it exists, it holds its slot, and it can be switched back on.
- **A built-in burst guard** — one Overseer may make at most **three** standing peers in any
  trailing hour. This is **not** your setting: it is always on and it does not move when yours
  does. It exists to catch an Overseer that has gone wrong minting a burst of paid always-on
  sessions in one sweep. Three in an hour is far past anything a working Overseer does, so an
  Overseer making a second peer next week is left alone.

The two refusals read differently on purpose. When your cap is the one that refused, the message
names the number and tells you to raise it in settings; when the burst guard refused, it says to
try again later — because one is a limit you chose and can lift, and the other is not.

### The review round — where an Overseer buys fresh eyes

An Overseer is woken by two schedules: a **heartbeat** (its regular check-in) and a **review**
(every six hours, a slower and wider look). The review exists because an agent cannot see its own
blind spots from the inside, so the round does not ask it to try — it asks it to **spawn a
reviewer**: a fresh, read-only session that reads the Overseer's own notes and ledger and reports
what it finds.

Successive reviews rotate through six **lenses**, so each round asks a genuinely different
question instead of re-finding the last answer:

| Lens             | What it asks                                                |
| ---------------- | ----------------------------------------------------------- |
| **META**         | Which of my own rules would have prevented my last mistakes? |
| **RED TEAM**     | Attack my findings and every "done" I accepted.              |
| **PATTERNS**     | What recurring shape am I still treating as separate instances? |
| **FRESH EYES**   | Re-derive the approach from scratch, without my priors.      |
| **INTAKE AUDIT** | What request never got a row, an answer, or a close?         |
| **SPEND**        | What did the period cost, and what was waste?                |

The Overseer records which lens is next in its own notes — for a crew lead, a decision line on its
crew log — because the reviewer is a fresh session that carries none of that memory. A reviewer is
normally capped at ten ranked findings, each with its evidence.

**Both of these abilities are named in the prompts an Overseer actually reads** — the standing
persona for a slot Overseer, and the wake prompts for a crew lead — which is the fix for a real
gap: both were fully built and documented while appearing in no prompt at all, so no Overseer ever
used either one. The two kinds of Overseer spawn their reviewer differently:

- **A slot Overseer** requests a `reviewer` worker through the agent-driven route. If that is
  refused (its allowed agent types may exclude `reviewer`), it says so.
- **A crew lead** spawns its reviewer through the normal pathway (`POST /project/<name>/new`), the
  same call it spawns every helper with. The agent-driven route refuses every crew session. The
  reviewer registers into the crew, changes nothing, and reads the crew's record itself.

Either way, a refused spawn is reported rather than quietly replaced by a self-review, because a
self-review reads exactly like a completed one. The copy ability splits the same way: a one-off copy
works for any Overseer, while a standing peer can only be copied from an Overseer slot.

### Giving one specific sessions to watch

A whole project is often the wrong unit. Open any Overseer's Settings tab in the hub and you can
name the **exact sessions** it is responsible for — the _Sessions it watches_ field, with a chip
per session and a search box to add another. The wizard's Scope step offers the same choice
(_Just these sessions_) when you set one up.

This is also what makes a custom Overseer useful. Before it, nothing routed to one at all: it
woke up, read its job description, and had no work attached to it.

Three things change once a session is assigned:

1. **Its alerts go to that Overseer** — not to its project's, and not to the global one.
2. **Its questions reach that Overseer** when the agent asks for guidance.
3. **That Overseer is told about it** — every wake-up lists the sessions it owns with their
   current status, project, and when they were last active.
4. **Its finished turns report to that Overseer, not to you** — see _Where a watched session's
   answers go_ below.

**A session has exactly one Overseer.** Add a session another Overseer already watches and it
_moves_; the dropdown says who currently has it, so that is never a surprise. The most specific
choice wins: an assigned session beats its project's Overseer, which beats the global one.

**Assigning pins a session; it does not narrow the Overseer.** Give the global Overseer three
sessions and it still covers everything else — otherwise every un-routed alert would have
nowhere to land. A per-project Overseer likewise keeps its whole project and simply picks up
the extras.

**A broken assignment quietly falls back.** Delete or switch off an Overseer that was watching
sessions and they revert to their project's Overseer, or the global one. Nothing is stranded.

The dropdown lists sessions that are still running — an Overseer watching a finished session has
nothing to do — and the list handed to the Overseer is capped, so a large assignment cannot
quietly multiply what every wake-up costs.

### Starting an Overseer from an existing session

If an ordinary session has been doing Overseer work, use **Use an existing session as a
template** in the hub's New Overseer wizard. This creates a real native Overseer; it does not
relabel or modify the old session.

The template copies only editable basics—its name, a bounded purpose, and its project scope. It
does not read or import the conversation, notes, files, hidden instructions, or other session
content. Review the purpose, scope, sessions, rhythm, allowed agent types, interrupt budget, and
cost before starting it.

Omniscio then performs the handoff in a safe order:

1. It creates and starts the native slot through the normal approval and keeper path, without
   moving any watched sessions.
2. The hub shows **Starting** until that exact slot has a canonical live session. A keeper failure
   changes the state to **Needs attention**; **Running** means the native session is live.
3. Only after **Running** does it move the sessions you reviewed. Each move succeeds only if that
   session still has the same owner it had during review, so a concurrent reassignment always wins.
4. Conflicts are reported and left untouched; successful moves are kept.

A startup failure or abandoned wizard leaves assignments unchanged. The old session is never
messaged, stopped, archived, deleted, or rewritten automatically. Keep it as history until the
replacement has completed whatever real operating proof you require, then archive it separately.

Custom Overseers still govern only sessions explicitly assigned to them. A specialist-sounding
name does not grant project-wide or fleet-wide authority.

### Doing it from the command line

`POST /overseer/sessions` moves one session in one call:

```jsonc
{ "sessionId": "<session>", "slotId": "custom:<id>" }   // assign (or move it here)
{ "sessionId": "<session>", "slotId": null }            // stop anyone watching it
```

The underlying setting (`overseerSessionAssignments`) is one whole map, so without this route
you would have to read it, edit it and write it back — and skipping the read would wipe every
other session's assignment. This route does that for you.

It is a convenience, **not a second way in**: it hands the result to the same approval step a
raw settings change goes through, so a session running inside Omniscio applies immediately and
any other caller is queued for you to approve. Nobody gains access they did not already have.

Two things it refuses rather than accepting quietly: a **session that does not exist**, and an
**Overseer that is not running** (deleted, switched off, or a project with no Overseer). Both
would be stored and then ignored forever, so the call would look like it worked and never do
anything — the worst possible outcome for a script. Removing an assignment skips both checks,
so a stale entry can always be cleaned up.

### Where a watched session's answers go

Once an Overseer watches a session, that session stops reporting to you and starts reporting to
it. The agent finishes its turn, its final message goes to the Overseer, and nothing appears in
your inbox — no card, no badge, no chime. The Overseer reads it, and only what it genuinely
cannot handle reaches you.

That is the point of an Overseer. Before this, one could command a fleet of agents and every one
of their answers still landed on you.

**Sessions an Overseer starts belong to it automatically.** You do not have to assign them — if
an Overseer spawned it, it owns it, and gets its reports back. An assignment you made by hand is
never overwritten by this.

**Questions go to it too.** If the agent ends its turn asking something, the Overseer answers it
when it can and passes it up when only you can decide.

**Some things always come straight to you, whoever is watching.** A request for permission and a
plan waiting for approval are your call, not an Overseer's, and they are never handed off. Nor
are the failure states an agent can get stuck in — a rate limit, a sign-in problem, an
interrupted response — because something else is already working on those.

**A watched agent can never be lost.** Three separate things bring it back, and only one has to
work: the Overseer replies and the agent carries on; the message fails to reach the Overseer, in
which case the agent comes straight to you as it always did; or thirty minutes pass with no
reply, and it appears in your inbox with its message intact. An Overseer that is switched off,
deleted, stuck, or simply ignoring an agent cannot swallow it.

**It is only ever quiet once the message has actually arrived.** The hand-off is not "assume it
worked" — if there is no Overseer running to receive it, or the delivery is refused, the session
never goes quiet in the first place.

You can turn the whole behaviour off and keep everything else about the Overseer — the
**Send their sessions’ replies to them, not you** switch, under _How they behave_ in
Overseer settings. Off, every session reports to you exactly as before.

### Giving each Overseer its own job

**Where:** the Overseers hub. **New** creates one through the wizard (purpose, scope, rhythm,
review — _Start watching_ is the approval to spend, _Save without starting_ keeps it unstarted);
the Settings tab of any Overseer edits its name, purpose and job, and its run switch starts or
stops it. A custom Overseer can be deleted from its Settings tab (it asks first) or simply switched
off, which keeps whatever you wrote for it. Every one of those edits goes through one writer in
the main process — the app itself never writes an Overseer's settings directly.

**An Overseer that has never been started says so, where you are looking.** Its Chat tab reads
"Not switched on — it will not start until you turn it on", with a **Turn it on** button that is
the same approval to spend as the Settings tab's run switch. An Overseer that HAS been started and
is simply between wake-ups still says "It starts on its next wake-up" — the two are different
situations and must never read the same way, because only one of them is going to start on its own.

Every Overseer has a **name** and a **job description**, both optional:

- **Leave the job blank** and it runs a built-in stock description — screen the inbox, answer
  agents, watch for patterns. Turning an Overseer on never requires writing a prompt first.
- **Write your own** and it _replaces_ the stock text rather than being tacked onto it, so an
  instruction like "only watch billing, ignore everything else" is not contradicted by stock text
  telling it to do everything.

**Don't want to come up with a name?** Describe what it's for in the **Purpose** field instead —
_"Watch the billing pipeline and flag anomalies"_ — and Omniscio turns that into a short title for
you automatically. Edit the Purpose later and the title updates to match, right up until you type
a Name of your own; from then on your name always wins, and further Purpose edits never touch it.
Already renamed it and want the generated title back? A **Use the auto title** button next to the
Name field clears it for you.

Names show up in the session list, so you can tell them apart: **Overseer**, **Overseer — Billing**,
or whatever you called your custom one. Without a name they would all read "Session 1", "Session 2".

Whatever you write, the safety half is always present and cannot be overridden by your instructions
or by anything an agent says to it: the prompt-injection lock, the tool list, and the memory rules.

A custom Overseer can be **paused** without deleting it — it stops running and keeps the job
description you wrote for it.

### Asking one a question

Its **Chat** tab in the hub is its real session: type a question, get an answer. _"What did I
miss today?"_ / _"Why is the billing project so noisy?"_ It has been answering your agents all
along; this is your way in. **Just us** shows only your exchange with it; **Everything it does**
shows the whole session, wake-ups and agent questions included. Swarms it proposes appear in the
same tab as cards you approve or decline.

### Why "Just us" is nearly empty compared to "Everything it does"

An Overseer's session is mostly machinery. Most of what is in there is the app talking to it —
the wake-up prompt every fifteen minutes, the "here are the alert cards to judge" briefing, and
the questions your other agents put to it — plus its replies to all of those. None of that is
addressed to you, so **Just us** leaves it out. What is left is what the two of you actually
said. On a busy Overseer that can be four messages out of a hundred and fifty, and that is the
view working, not a bug.

Two things decide it, and neither is a guess:

- **The app knows which turns it injected.** A turn only counts as yours if you actually typed
  it. A briefing can never pass as your message, even one sent by a part of the app that forgets
  to label itself.
- **The Overseer can quiet one of its own replies.** When it answers you but the answer is just
  a routine status update — "done", "still watching" — it can tag that reply and it stays out of
  **Just us**. It decides; you never have to configure anything.

Nothing is ever deleted. A tagged reply is still in the session, still searchable, and shows in
full under **Everything it does**. And the tag has limits the Overseer cannot talk its way past:
it can only quiet its own answers, never anything you wrote; a reply that is asking you something
always shows; and the answer to your most recent message always shows, so you are never left
looking at your own question with silence under it.

### Telling one it got it wrong

Any row on its **Board** tab where an alert was **kept from you** — silenced, merged, or still
being held — carries an **"I wanted this"** button. Pressing it does three things:

1. **Brings the alert back**, so you get the thing you missed.
2. **Writes the correction into that Overseer's notes**, so it still knows tomorrow.
3. **Tells the running Overseer immediately**, so it applies today rather than waiting for its
   next restart — up to 24 hours away.

The confirmation says which of those actually happened. If the original alert was already gone,
it tells you that rather than claiming everything worked.

The button doesn't appear on alerts that reached you normally — there'd be nothing to correct.

## Related

- [Overseers](overseers.md) — part 1, what an Overseer is and how you create one.
- [Overseers part 3](overseers-part-3.md) — the work it hands out, its settings and the internals.
- [agent-status-board.md](agent-status-board.md) — the board that shows what the fleet is doing right now.