Reviewed 05/10/2026

Script Results & Output Logs

Phase 5 — Scripts & Automation · OpenFrame Onboarding

Running a script is only half the job — you need to know whether it worked. OpenFrame doesn't show output inline when you hit Run; instead, every execution is recorded in the activity logs. This guide shows you where results land and how to read them when something fails.

Where results go

When you run a script, OpenFrame confirms with an Execution Started message — "Script [name] has been accepted for execution. You can track the progress and view the results in the activity logs section." It hands you a View Logs shortcut straight to that section.

The activity logs live under Logs in the left nav. You can get there from the run confirmation or open it directly any time.

Reading the Logs stream

The Logs page is a running feed of everything happening in your tenant. For script runs you'll see entries like:

• Script '[name]' completed — the per-device result, with Tool = RMM and Source = the device that ran it.
• RMM executed bulk script: [name] on multiple agents — the umbrella entry when you ran one script across several devices.

Each row shows:

• Log ID — the unique ID (and timestamp) for that event.
• Status — e.g. INFO.
• Tool — which subsystem reported it (RMM for scripts, Fleet for queries, etc.).
• Source — the device (or System) the event came from.
• Log Details — the human-readable message.

Use Search for Logs to find a specific run, the column filters to narrow by Status or Tool, and Refresh to pull the latest (runs are queued, so a result may take a moment to appear).

Drilling into one run

Click the eye icon on a log row to open Log Details — a side panel with the Log ID, Source, the Device it ran on, and a Details button that jumps to that device (with its online status and last-seen time). This is how you tie a result back to the exact machine.

Debugging a failure

When a run doesn't do what you expected, work through this:

1. Did it even run? Find the Script '[name]' completed entry for the device. No entry usually means the device was offline or the OS didn't match the script.
2. Did the inputs land? The most common silent failure is a variable passed the wrong way — a value sent as a Script Argument when the script reads an Environment Variable (or vice versa). Re-open the script's Syntax and confirm which it expects, then re-run with the value in the right field. (Full explanation in Run a Script on a Device.)
3. Did it time out? If the script does more than its Timeout allows, OpenFrame stops it. Raise the timeout on the script (or on the run) and try again.
4. Use Test Script from the editor so you're debugging one result, not a fleet of them.

Quick checklist

• Found the run in Logs (Script '[name]' completed)
• Matched the Source device to the result via Log Details
• For failures, confirmed the device was online and OS matched
• Re-checked Argument vs Environment Var for any input that didn't take
• Raised the Timeout or re-tested on a single device when needed

What's next

That completes Phase 5 — Scripts & Automation. Next up is Phase 6 — Tickets & PSA Workflow, where script-driven fixes and alerts start flowing into tickets — and where Mingo AI lends a hand.

Based on OpenFrame v0.9.19. The activity logs and where raw script output surfaces are actively evolving — re-check the console if an entry looks different from what's described here.