> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ImmyBot Environment Review

> Review an ImmyBot tenant's computers and maintenance-session history — what ran, what failed, and which machines keep failing — read-only. Use for "did last night's ImmyBot maintenance succeed", "why didn't <software> deploy to <device>", or an ImmyBot coverage check.

<Info>
  **Category:** Devices & Infrastructure · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/devices-and-infrastructure/immybot-environment-review/SKILL.md)
</Info>

**Connectors:** `ImmyBot`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** "Did the ImmyBot maintenance run for \<client> last night? Anything fail?", "why didn't \<application> install on \<device>?", or checking which machines are enrolled at all.

**Run it:** on one computer, or across a whole tenant/maintenance window, on demand (not a Flow — it's a read-only review, not a per-ticket event).

## Prompt

```
Answer ImmyBot deployment questions from session history instead of guesswork. Read-only. Requires ImmyBot; if not enabled, say so and stop — do not substitute RMM data as if it were deployment history.

1. Resolve the client to an ImmyBot tenant. Rank name matches and state your pick; only ask when genuinely ambiguous.
2. Scope the question: whole-tenant, one computer, or one maintenance window.
3. Tenant review: pull the ImmyBot enrollment list (flag result caps — report floors). Then read the maintenance-session history over the window (default last 7 days) and bucket sessions: succeeded / failed / partial / not-run. Group failures by what failed (a software's detection or install step, a pending-reboot precondition, machine offline at session time) and by machine — a machine failing every session is different from a package failing on every machine.
4. Single computer: pull the computer's ImmyBot identity and state, then its maintenance-session history — what ran, what failed, and the failure detail per step. Correlate "offline at session time" failures with the RMM view if a health check has been run.
5. Read the failure texture before concluding: installer exit codes and detection-script failures point at the package; timeout/unreachable points at the machine or network; a pending reboot blocking everything points at basic hygiene. Report what the session record actually says, quoting the failing step's status rather than paraphrasing into certainty.
6. Output: coverage count, session outcomes over the window, failure clusters (by package and by machine) with evidence, and recommended next actions — retry after reboot, fix the package, enroll the missing machines. Offer a plain-text summary note (no markdown/emojis).

Guardrails: read-only today — this integration cannot start, retry, or modify maintenance sessions, and cannot deploy software; every "retry"/"fix" is a recommendation for a tech to action in ImmyBot, never claimed as performed. Do not infer success from absence — a machine with no session in the window "did not run", which is not "passed". Failure causes come from the session record; where ambiguous, say so instead of picking a cause. Result-cap honesty on computer and session listings.
```


## Related topics

- [Use ImmyBot with Super Magic](/super-magic/use-immybot-with-super-magic.md)
- [RMM Cross-Tool Reconciliation](/skill-library/devices-and-infrastructure/rmm-cross-tool-reconciliation.md)
- [Changelog](/changelog.md)