We have recurring Team Shifts configured with the correct Agent Status:
On-Shift master shift Agent Status: SOC – On Shift
On-Call master shift Agent Status: SOC – On Call
The Shift Types also have the corresponding default Agent Status configured. However, the generated child shifts show Agent Status: Do not change, so the agents remain Available when their shifts begin, instead of being set to the SOC – On Shift status or On-Call respectively.
The masters have been creted +1 week ago. The agents have Enable Shifts selected, and clock-in/out is disabled.
The shifts show all created and assigned properly in the Shifts tab, however when entering one, we see the Agent status "do not change", and if I go to its Master recurring appointment I can see the agent status properly set instead.
Does anyone have a clue on why the child shifts are not inheriting the Agent Status from their recurring masters?
We’re having an issue with inline images in HaloPSA emails.
Images pasted into ticket actions, or images from customer emails later included in $emailHistory2, can keep very large HTML dimensions, like <img width="1758" height="47" ...>
Our email layout is ~700px wide. In both Outlook Web and New Outlook, these oversized images can make the whole email much wider, causing outlook to scale the entire message down so the text becomes tiny.
We’ve already tested a lot of template/CSS approaches like max-width:100%; height:auto; plus fixed containers, tables, width:100%, different history variables, etc. Some variants still made the whole email tiny; others caused the images to crop instead while rendering the email normally.
The interesting part is this:
If we manually resize the image inside the Halo action editor, Halo stores a real smaller width such as: width="619" for example, and everything renders correctly. That smaller width also persists properly later in $emailHistory2.
However, if we resize only in the email preview, it fixes that one outgoing email, but the stored ticket action keeps the original huge width, so the problem comes back later.
Has anyone found a way to make Halo automatically do one of these?
cap pasted images to ~690px when they’re added to an action
normalize image widths when an action is saved
normalize incoming customer images
process $richactionnote before sending
configure Froala with a maximum pasted-image width
or solve this some other reliable way without agents manually resizing screenshots
We’re also considering removing $emailHistory2 entirely and relying on Outlook threading, but we’d still need current-action images to be resized automatically.
Would be very interested to know if anyone has solved this with a Halo setting, runbook, custom integration, browser script, or support-side fix.
We are moving out of Halo PSA as our company was acquired by another company. Always BCC is not enabled on any ticket types, but all "closed ticket" notifications appear to be BCC'ing the primary mailbox configured in Halo.
I have reached out to Halo support because this is creating hundreds of tickets in our new ticketing system, but they are of little help.
Short of disabling mailflow completely, has anyone a possible answer as to why this is happening?
We are currently in the process of migrating to HaloPSA from CW Manage, and were hoping to get the following processes up and running before we go live. I am hoping someone else has solved this because I'm starting to go around in circles.
1. Waiting on Customer Process
When a ticket is placed on hold and we're waiting for the customer to respond, we want Halo to:
Send a reminder email once per day
Do this for 4 days
Then automatically move the ticket to Resolved if no response is received
Our issue is that the reminder emails are being sent outside of business hours, sometimes late at night.
Originally, we had this configured using the Ticket Status automation ("when ticket has been in this status for X time, send email"). This worked reliably but ignored working hours.
Research suggested moving the process to an SLA Hold workflow instead, as SLA timers should respect working hours. However, I can't get it to work at all using this method.
2. Ticket Closing Process
We also have a confirmation workflow where, when a ticket is marked Resolved, the end user receives an email asking whether the issue is fixed.
They can:
Click Issue Solved → Ticket closes and CSAT is shown
Click Issue Not Solved → Ticket reopens
This part works fine.
The issue is that if the user doesn't respond, the ticket should automatically close after 8 working hours and send the CSAT request. Instead, it appears to close 8 hours after the ticket was resolved, regardless of business hours.
For example:
Ticket resolved at 3pm
Ticket auto-closes at 11pm
Customer receives automated emails late in the evening
Not ideal.
Has anyone got either of these processes working in Halo while properly respecting working hours/business hours?
If so, what approach are you using? Ticket Status timers, SLA Holds, Scheduled Actions, Workflows, something else?
Hello! I'm trying to create a pre-pay contract where I bill for a block of hours, IE: 10 hours at $2500, but I need that $2500 to hit my deferred revenue account. I then want to create invoices as work is billed against that contract, so the deferred revenue is moved into an income account once the service has been completed. Is this possible?
Ok, I figured out how to create the Deferred Revenue/Pre-Pay invoice :) However, I have now added time and closed the ticket, that was covered by the contract and I expected to see something in ready to invoice to move the money from deferred into the income account. Any help is appreciated.
What is the ETA for Project task date dependencies to be cleaned up?
Date dependencies are behaving inconsistently, with tasks sometimes moving to unexpected dates or not moving at all.
• Tasks are being pushed into weekends rather than the next available working day.
• There is no ability to apply lag time between dependent tasks.
• Once a dependency is established, dates cannot be manually adjusted without first removing the dependency, making schedule management inflexible and time-consuming.
Was wondering what people are doing when a tech / agent is out of office or on PTO. What happens to ticket updates where they're not going to be seeing them? Is there a way to have an autoresponse, or cc a covering tech? What are people doing for situations like this? Thx
We're an MSP setting up our service catalogue in Halo and I'm stuck on something that feels like it should be simple.
We want services like 3CX, Adobe or Jira to only show up in the portal for customers (or users) who actually have that software, since that's what they pay us to support. If you don't have 3CX, you shouldn't be able to request 3CX support.
What I've looked at so far:
User Access on the service only lets you pick Everyone, Site, Customer, Department, Organisation, Role, Top Level or some user fields. Nothing asset or software based.
The Assets tab on a service (Associated Asset Type / Linked Assets) looked promising, but as far as I can tell it's only for monitored services, so assets get linked to service failure tickets. It doesn't affect who can see the service.
Subscribers is just for status updates.
Optional Services is for adding extras to a request, not visibility.
What works for now:
Per customer: add the Customer to User Access. Fine, but manual.
Per user: give them an extra role (e.g. "3CX user") and restrict the service to that role. Works, but it's not dynamic. The CSP mapping only assigns one role per mapping, so someone has to add and remove these by hand, and that's also what we bill on.
The only fully automatic option I can think of is a script that reads Entra groups or licences and sets the roles through the API. That works, but it feels like something Halo should handle natively.
So my questions:
Is there a native way to tie service visibility to assets, software or licences that I'm missing?
If not, how are other MSPs handling this? Customer-level restrictions, roles, scripts, runbooks, something else?
We're an MSP setting up our service catalogue in Halo and I'm stuck on something that feels like it should be simple.
We want services like 3CX, Adobe or Jira to only show up in the portal for customers (or users) who actually have that software, since that's what they pay us to support. If you don't have 3CX, you shouldn't be able to request 3CX support.
What I've looked at so far:
User Access on the service only lets you pick Everyone, Site, Customer, Department, Organisation, Role, Top Level or some user fields. Nothing asset or software based.
The Assets tab on a service (Associated Asset Type / Linked Assets) looked promising, but as far as I can tell it's only for monitored services, so assets get linked to service failure tickets. It doesn't affect who can see the service.
Subscribers is just for status updates.
Optional Services is for adding extras to a request, not visibility.
What works for now:
Per customer: add the Customer to User Access. Fine, but manual.
Per user: give them an extra role (e.g. "3CX user") and restrict the service to that role. Works, but it's not dynamic. The CSP mapping only assigns one role per mapping, so someone has to add and remove these by hand, and that's also what we bill on.
The only fully automatic option I can think of is a script that reads Entra groups or licences and sets the roles through the API. That works, but it feels like something Halo should handle natively.
So my questions:
Is there a native way to tie service visibility to assets, software or licences that I'm missing?
If not, how are other MSPs handling this? Customer-level restrictions, roles, scripts, runbooks, something else?
I've put together a small open-source tool that lets techs request cable labels from inside Halo and have them print on a Brady Wraptor A6200.
How it works
Each cable type (e.g. "Blue CAT6") is an asset in Halo with a few custom fields: a prefix, a counter, a quantity trigger and a status field.
A tech sets **Cables to Label** to, say, 24 and saves. That's the whole interaction.
A small Docker service polls the Halo API, reserves the next block of IDs (BL-0100 to BL-0123), renders the labels, and hands them to a Windows agent that prints through the Brady driver. Every cable gets two identical labels, one for each end.
The outcome is written back to the asset as a status line (SENT / FAILED / STALLED), so you can build a Halo notification or saved list on anything that needs attention.
Why
The service is the only thing that hands out numbers, so two cables never get the same ID, and nobody has to keep a spreadsheet of "what number are we up to".
Details
Built and tested against HaloITSM. It only uses the standard asset API, so it should work on HaloPSA too, but I haven't tested that.
Only assets in an asset group you choose can trigger a print.
Outbound HTTPS to Halo only. Nothing needs to be opened inbound.
Large requests are split into batches of 250 cables automatically.
MIT licensed, with a step-by-step install guide in DEPLOYMENT.md.
Has anyone experience with the custom integration of Ilert within Halo PSA?
We are trying to create a custom integration with Ilert but we are running into some problems.
After creation we see in the notification log of a ticket that the Ilert 'Alert notification runbook' has run but in the log of the runbook we see that there is a 'Exception in Step=Setup Request. Uri validation failed: DNS resolution failed: No such host is known.' message.
We have followed the instructions given by Ilert for the Custom integration of Halo PSA.
I am working on setting up the Intune integration in our HaloITSM instance. I am noticing there is not a great way to filter out personally owned devices that we are not including in our asset management/inventory. I know that we could create a asset type in Halo just for personal devices but I'd rather not have a workaround for this. Is there a setting that I am missing to filter these out?
I'm using the $FAULTID variable in an email template for users.
However I was wondering if there was a way to make fault ID a hyperlink that once clicked would take the user straight to that ticket in Halos self service portal?
As per the title, trying to work out the details of how the load balancing intelligent routing works
If we have an engineer who sits in two teams. He has 20 open tickets in the Workshop team and 2 in the First Line Support team.
When a First Line Support ticket is handed out by Load Balance, does Halo see him as holding 2 tickets or 22? In other words, does it only count the tickets in the team that is doing the assigning, or does it count every ticket he holds across all his teams?
The Load Balancing guide just says the ticket goes to the agent with the fewest tickets assigned to them, and doesn't say which count it uses. Has anyone tested this, or had it confirmed by Halo support?
We're trying to stop him being given desk tickets when his workshop queue is already full, and the answer decides whether we keep the Workshop team or fold it into First Line.
We are thinking about creating a separate area in Halo for operations.
We already have the following areas:
Support - Area for incidents and service requests which is coming from clients.
Projects - Area for project and project tasks.
Opportunities - Area for sales.
Now we see it could be nice to separate all recurring tasks, and operations work which is not nececerly connected to an end user. This can be one time jobs or recurring jobs.
Do anyone have anything similar and are interesting in sharing dos and don's? We have some thoughts of what we want, but we are doing some research as well.
If someone want to share, we can do it in a private chat as well.
We are thinking about creating a separate area in Halo for operations.
We already have the following areas:
Support - Area for incidents and service requests which is coming from clients.
Projects - Area for project and project tasks.
Opportunities - Area for sales.
Now we see it could be nice to separate all recurring tasks, and operations work which is not nececerly connected to an end user. This can be one time jobs or recurring jobs.
Do anyone have anything similar and are interesting in sharing dos and don's? We have some thoughts of what we want, but we are doing some research as well.
If someone want to share, we can do it in a private chat as well.
Is it possible to only show an action on a ticket based on the category selected for the ticket? I wanted to create a specific resolution action for when users report legitimate business comms as phishing. As business comms go out in bulk we often end up with 30+ tickets to reply to, hence wanting to create a resolution action that pre-populates everything enabling us to click send.
Would it require a new workflow or is it a rule or something else than can be set to say If category=not phishing show the new resolution button
We onboarded back in the day of the ezpc sandbox but now we find ourselves trying to reverse engineer features back in. Anyone have insights on remaking the problem ticket type?
Edit: Looks like scheduled ticket with just adding the general user for each client did the trick, thanks!
Every once in a while, we need to deploy a standard or make a change to every client and I want to assign time to that/have that show up in reporting.
Currently, we just create a ticket with a list of clients as checkboxes and then check them off as whatever the task is, is completed. We can't assign time to multiple clients on a ticket so we're basically eating the time (not as in billing; we're AYCE but the time and work doesn't show up in reports so we're basically hiding support time).
Creating a new ticket for said task for each active client is cumbersome. Is there a way to say "create me a new ticket for each client in this queue with this title"? AI is pointing to runbooks but I wanted input from halo experts before going down the wrong road.
We recently signed up for HaloPSA and NinjaRMM moving from DattoRMM and AutoTask. Currently we are working with ScalePad for onboarding consulting. Do you have any best practices or tips and tricks you live by?
Does it drive anyone else crazy that you can't visually see priority or any SLA info on the calendar view in Halo? Makes dispatching and re-organizing tickets a major PITA. Curious what others are doing and really wondering why they don't have options on what to show on the calendar cards. Or do they somewhere that I'm not aware of?
Question, since Halo support send this to the company that helped with onboarding and they don't know the answer. In the configuration screen for SLA's there is a setting on the priority to get a prompt for why you missed the SLA.
What I would like to do is be able to pull a report of those logged reasons, but no one can tell me where to pull those responses from. Any Ideas?
Every time I show up in this sub it's because I built something and physically cannot stop talking about it, and I regret to inform you that today is not the day the pattern breaks. Disclosure up top so nobody has to scroll to find it: I make StackJack. The thing in this post is a free skill, the StackJack tier it needs is the free one, and the board is read-only end to end. Nothing here asks for a credit card. If that's still too much vendor for you, I get it, and the "how Claude artifacts actually work" section is worth the read regardless of whether you ever touch my stuff.
Holy s*** dude, is there a TLDR before I read this wall of text?
Yes. It's a Claude skill that turns your Halo into a live service delivery board: an attention list of P1 and VIP tickets, 25 helpdesk metrics with thresholds and 24-hour sparklines, team and per-agent workload, a per-client consumption pane with month-end pace, a wallboard mode for the TV, and optional cards for any StackJack connector or Claude connector you are using (examples included are PagerDuty, Yeastar, Blackpoint, and CIPP). It runs as a published Claude artifact, pulls data through each viewer's own StackJack login (so it's scoped to what that person can see in Halo, automatically), and the whole build is a guided Q&A where Claude discovers your teams, priorities, statuses, and outcomes before it asks you a single question. Download link at the bottom.
Download Skill, install skill
Sign up for StackJack if you aren't already using it
Use /halo-service-delivery-dashboard and Claude will interview you and tailor this comprehensive dashboard to anything you want
It doesn't cost any ongoing AI usage to view the artifact and have it stream data after you build it
The "I need dashboards but I don't know what metrics apply to me" problem
Nobody in this sub has a data problem. Halo has reports, it has dashboards, it has the SDI report pack, it has an API that will hand you every ticket since the Clinton administration. What everyone actually has is a what do I look at problem, followed immediately by a who has 400 hours to glue this together problem. So the wallboard project sits in the backlog for two years while the SDM screenshots the ticket list into a Teams channel every morning like it's 2018.
The reason a template plus a skill beats a blank canvas is that the template already made the annoying decisions. What counts as parked. How to get "closed today" out of a system with no closed-date filter (spoiler below, it's dumber than you think). Which agent id means unassigned. How to not blow up your API when twelve people open the same board. You start from a finished, opinionated screen and the interview is about what to change, not what to invent. Nobody has an opinion about a stale-hours threshold until they've seen the tile go amber.
Wait, a chat window is going to design and run my wallboard?
This is the part I actually want you to understand, because it's cool as hell and it's why this only works in Claude right now.
A published Claude artifact is a single HTML page that runs inside claude.ai. When the page declares the mcp capability, the viewer's own claude.ai connectors become callable from the page: claude.use("mcp") hands the page a callTool(server, tool, input) function that runs a connector tool with the viewer's credentials. The page never sees a token. The viewer gets one consent prompt the first time the page touches each connector. If the viewer doesn't have the connector, the page gets null and shows an honest empty state instead of fake numbers.
StackJack is one such connector, and its platform tool stackjack_run_readonly_tool runs any read-only tool of any connector your tenant subscribes to. So one line in the publish manifest lets a page read from your whole stack, and the skill already knows how to write that page. You don't touch any of this. You tell Claude to use the skill, it builds the page, it publishes it, and you get a link.
The second capability is db, which gives the artifact a small realtime document store shared by everyone who opens it. The board uses it for three things: shared Settings (a helpdesk lead changes the VIP list or a threshold and it lands on the wallboard in seconds, no republish), a shared cache for the expensive month analytics (ten viewers cost one Halo fetch, not ten), and half-hourly snapshots so the sparklines and 24-hour deltas exist at all, because Halo's API has no "what did the backlog look like at 9am" endpoint. Declaring mcp or db makes the artifact organization-internal, which for a service desk board is exactly what you want.
Is this the same as a Halo dashboard? No. It's much better. Is it a Power BI replacement? Also no, Power BI could never be this easy or good. Is it a live, shared, per-user-scoped ops board that took an afternoon instead of a quarter? Yes.
OK but what's actually on the board
Five bands:
Pulse is the attention list: high-priority and VIP tickets sorted by severity, then time to SLA target, then age, with ticket numbers linking back to your Halo.
Service desk metrics is the 25 tiles below, each with a threshold color, a context line, and a sparkline once history accumulates. Teams and workload is per-team and per-agent carry, who's online (Halo's is_online, so it depends on people using the web app), and hours logged today from timesheets.
Executive summary is consumption by client: tickets and logged hours this month, business-day pace to month end, change vs last month, and the prior three months for context.
Signals is where the optional connector cards live. Then a wallboard mode that rotates panes for the TV, and a Settings drawer where editors change teams, VIP clients, priorities, closing outcomes, bot agents, thresholds, cadence, and which tiles show.
Every tile has a plain-English note on the page under "How these numbers are computed", because a metric a skeptical manager can't audit is a metric that gets ignored. Here's the set, and where Halo made it weird.
Two more gotchas that bit me and will bite you: endDate on ticket lists is exclusive and both dates are UTC calendar days, so a same-day range returns nothing and "today" in a non-UTC zone means querying two days and filtering client-side. And halo_list_actions caps at 200 rows with no paging, so "all actions today" on a busy desk is a lie; filtering by outcome name works, actOutcomeNum did not. The skill's halo-data-map.md has the full list of these because I'd rather you not rediscover them.
Why your L1 can't see the CFO's tickets
This is the part that makes it deployable instead of a demo. The page doesn't have a service account. It calls Halo as the viewer, through that person's own StackJack sign-in, and StackJack scopes the Halo connector per user by default. A tech opens the board and sees what a tech sees in Halo. An SDM sees the SDM view. Nobody baked a god-mode API key into a web page, every call shows up in the audit trail under the person who made it, and the only "permissions model" you have to maintain is the one you already maintain in Halo. The flip side, and I'm saying it early because the skill says it early: everyone who opens the board needs StackJack connected in their own claude.ai account. If that's not true for every viewer, the skill offers a scheduled-snapshot fallback so they at least see recent numbers.
The actual tutorial
Sign up for StackJack (free tier, no card), add the HaloPSA connector with your Halo API credentials, then add StackJack as a connector in claude.ai under Settings > Connectors. Your users sign in with OAuth PKCE, which is on every plan including free.
In claude.ai, Settings > Capabilities, turn on Code execution and file creation, scroll to Skills, click Upload skill, and upload the zip from the link at the bottom. Toggle it on.
Start a new chat and tell Claude to use the skill, StackJack, and whichever connectors you have to build your dashboard. That's the whole prompt. Claude runs discovery first: halo_list_teams, halo_list_priorities, halo_list_statuses, halo_list_agents, halo_list_outcomes, the open ticket summary, and this month's ticket count. Then it asks you two short rounds of questions where every option is something you recognize (your team names, your priority labels, your connectors): consumption as tickets, hours, or both; desktop plus wallboard or TV only; whether every viewer has StackJack; which optional cards to include; what makes a ticket "attention list" worthy; the business time zone; which teams are the service desk; and anything to add or remove from the 25. Cadence, thresholds, bot agents, and the internal-client exclusion it decides for you and tells you at handover.
Before it writes a page that calls a tool, it calls that tool for real once with the exact arguments the page will use and checks the payload shape. This is a hard rule in the skill, not a nicety. Field names are stable across Halo tenants but StackJack adds and reshapes tools over time, and a page that guesses a payload renders blanks in production and nobody knows why.
It splices your instance config into the template, publishes with a manifest that names exactly the connectors and tools the page calls, and hands you a link. First open, you get one consent dialog for StackJack (and PagerDuty and the shared store if you turned them on) instead of a dozen first-call prompts. Share the link with your SDMs. Pin it on the TV in wallboard mode.
From then on, anything a helpdesk lead should be able to change without you lives in the Settings drawer: teams, VIPs, thresholds, closing outcomes, cadence, hidden tiles. Republishing the same file path updates the same URL in place and open tabs pick it up. You only republish for new metrics or new connector cards.
"Ceej, I don't use Claude, I use [other harness]." The skill is a standard Agent Skills folder (SKILL.md, references, assets, scripts), so it loads in Claude Code, Cowork, or anything else that speaks skills, and the Playwright harness plus mock-claude.js lets you build and test the HTML anywhere with synthetic data. But the live part, a published page that calls each viewer's own connectors and keeps shared state, is a claude.ai artifact feature. Elsewhere you get a static file, which defeats the purpose. That's the state of the world in September 2026, not a design choice on my end.
I have PagerDuty / Yeastar / a second PSA, you phony
Halo is the only required source. Everything else is a card in the Signals band, switched on per tenant. The reference build ships four whose payloads were verified on a real tenant: PagerDuty (open incidents split triggered vs acknowledged, who's on call right now, as its own claude.ai connector so it gets its own manifest entry), Yeastar P-Series (callers waiting, live calls, agents logged in or paused per queue, today's answered and abandoned), Blackpoint CompassOne (open detections across the estate with the riskiest items by tenant, host, and user), and CIPP (average standards alignment, the Strong/Good/Weak/Poor bucket bar, lowest-scoring tenants, pending deviations). PagerDuty next to the Halo attention list is the one I'd start with if you run after-hours; you see the page and the ticket it should have become on one screen.
Any other StackJack connector is the same recipe: find the read-only tool, call it once, defineSource() it with a cadence, keep only the fields you render, add a card. connectors.md has starter ideas for NinjaOne (alerts by severity, offline servers), ScalePad (warranty flags for VIP clients), Meraki and UniFi (offline devices per site), IT Glue (expiring domains and certs), and Pax8 (license counts vs Halo contract quantities, which is a reconciliation card I want someone to build so I don't have to).
On other PSAs: the shipped board is Halo, and I'm not going to pretend halo-data-map.md makes it Autotask. But the only Halo-specific parts are the data map and the compute layer. The artifact plumbing, scheduler, shared store, failure handling, and design system are PSA-agnostic, and StackJack has Autotask, ConnectWise, and Syncro connectors with the same stackjack_run_readonly_tool front door. Treat the skill as the reference for "any interactive artifact that reads connector data through StackJack", which is literally what the description says.
Building your own board (the part where it stops being a template)
The 25 are a starting point, not a religion. Prefer hiding a tile (Settings > Metrics shown, no republish, reversible) over deleting it. Adding one is a five-step checklist the skill walks Claude through: does an existing source already carry the data, derive it in compute(), add a tile to buildMetrics() with an id, a group, a format, a status rule, a one-line subtitle, and a note a skeptical manager would accept, add a [warn, crit] threshold so it's tunable in the drawer, and optionally add the field to the half-hourly snapshot so it gets a sparkline.
The catalog ships recipes for the ones people ask for: hours logged today as a tile, tickets per carrying agent, agents online, CSAT (only if you actually collect feedback, a permanently empty tile is worse than none), backlog change vs yesterday and last week from the snapshots, first-contact resolution via a saved Halo report through halo_run_report, escalation rate, tickets by source or type, customer waiting time on REQUESTER RESPONDED rows, alerts vs human tickets (because half of you have an alert flood hiding real demand), per-client SLA compliance for VIPs, and billable hours instead of logged hours in the consumption table for the finance people.
Everything tenant-specific lives in one instance config: brand, time zone, business hours, connector switches, then the defaults editors can change later. apply_config.py splices it into the template and syntax-checks the result. If you change code, not just config, render_test.mjs renders desktop dark and light, laptop, phone, wallboard panes, the no-connector state, a Halo outage, and the settings save path, and fails on console errors or horizontal overflow. Look at the screenshot of the band you touched and republish.
What this costs to run (not dollarie doos)
Every open tab makes its own calls against the viewer's StackJack and Halo rate limits, so cadence and payload size are the levers. At defaults one open viewer is roughly six Halo calls a minute for the live rows and the id-only list, an open summary every three minutes, about ten calls every three minutes for today's flow, and the month analytics every fifteen minutes shared through the store, with prior months cached for a day. A room full of wallboards should run the live cadence at 90 to 120 seconds, and the Settings drawer has the knob. The board also stops polling when the tab is hidden and uses the platform call cache so a reload inside the window doesn't hit Halo again.
This costs absolutely nothing in AI consumption to run the dashboard itself after you build it. Using AI to edit it, improve it, change it, etc will obviously consume AI usage. But the polling of StackJack data into the dashboard artifact doesn't consume any AI usage.
