OpenFrame

Script Results & Output Logs

AUTOMATIONDOCUMENTATIONOPENFRAMETUTORIAL

Phase 5 — Scripts & Automation · Step 5

Section

June 19, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

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 = Tactical and Source = the device that ran it.
  • tactical 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 (Tactical 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. Is it the right script? Check the Category — anything marked DEPRECATED won't behave and shouldn't be used.
  5. Test in isolation. Re-run against a single known device (or 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.

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Hi all! My name is Vlad and I’ve been brought on to head the marketing team at Flamingo. Thankfully, this isn’t the first time I will be building a marketing department from scratch, so the experience should come in handy. Now it’s time to dive into the world of MSPs and find myself in this new world.

More in Phase 5 — Scripts & Automation

Related Content

Product Releases

Webinars

Case Studies

Blog Posts

Frequently Asked Questions

MSP AI Agents

Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.
On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.
An AI agent for an MSP is software that reads a ticket, decides the action, performs it across your tools, and records the result without a technician driving each step. It differs from a chatbot or copilot by taking action, not just suggesting one.

AI MSP

MSPs use AI to triage and route tickets, cut alert noise, schedule patches, assist L1 security work, and draft client reports. Kaseya's 2025 benchmark found 30% already use it to eliminate tedious tasks, with ticket triage the most common starting point.
Start with a readiness assessment, not a tool purchase. Confirm your ticket history is clean and your RMM, PSA, and monitoring systems connect. Then pick one high-volume, low-risk workflow, usually ticket triage, and pilot it on internal tickets before any client sees it.
Automate high-volume, low-risk tasks first. Ticket triage and alert noise reduction top the list because they run constantly and a human still resolves the underlying issue. Save security approvals, billing changes, and client-facing actions for later, always with a human in the loop.

AI for MSPs

Set a baseline before rollout, then track tickets closed per technician, mean time to resolution, percentage of tickets resolved with no human touch, technician hours reclaimed, and cost per ticket. AI-driven automation commonly cuts operational cost per ticket by 25 to 40%.
No. AI automates routine tickets, patching, and monitoring, but trust, accountability, and complex business judgment still need people. The future of managed services moves technicians from closing tickets to advising clients, which makes the human role more valuable, not obsolete.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.

IT Documentation

Hudu is IT documentation software that MSPs and internal IT teams use to centralize client documentation, network details, encrypted passwords, IT assets, and SOP runbooks in one searchable platform, so technicians find what they need without digging through scattered files.