No More Hard Refresh After a Release

August 16, 2026 · InfraScout Team

Most of this release is a collection of things that were quietly wrong. None of them were features anyone asked for; all of them were friction you had probably learned to work around. Here is what changed.

The app stopped freezing after a deploy

The portal often needed a hard refresh after a release before it worked again, and the symptom was not an error — it was nothing happening. Click a link, and the page simply did not navigate.

A deploy replaces the entire set of versioned assets. A tab left open from before the deploy is still running the old page, holding references to files that no longer exist, so the next thing it tried to load in the background failed and the navigation silently gave up. The exposure was wide: every lazily loaded view, the chart panels, the syntax highlighting and diagram rendering — and the sign-in library itself, which means a stale tab could fail to log in.

The portal now recognizes that failure for what it is and reloads itself once, throttled so it can never loop. You get a brief reload instead of a dead tab.

Two ways sign-in could wedge

In a long-lived tab, every request could start failing with an authorization error and no redirect to sign in again — the app just sat there. Behind it, the sign-in state considered you still signed in because your account was cached long after your token had died, so the recovery path checked that flag and did nothing. A hard reload was the only escape.

Fixing that exposed a second one immediately: signing in from any URL other than the portal root looped back to the identity provider until the retry budget gave up and hard-stopped the tab permanently. Refreshing did not help; only a new tab or clearing site data did. A deep-link sign-in returns across two page loads, and the response was being stashed on the first and discarded before the second could redeem it.

Both are fixed. A bookmarked deep link into the portal now signs you in and lands where you were going.

The dashboard reports what actually happened

Every row under Recent sessions showed 0 cmds · 0 insights regardless of what the session had actually done. The counts were real and available; the dashboard was simply never sending them. The single-session view had solved this long ago, and the dashboard now returns the same shape, so the two agree.

The activity heatmap had a subtler version of the same problem. Its color bands were fixed constants — nothing, one to five, six to twenty, more than twenty — chosen when a busy day meant a dozen executions. Measured against real traffic over an eight-week window, fifty-two of fifty-three active days landed in the top band. The grid had degraded into a map of whether anything happened at all, painting a 22-execution day and a 195-execution day the same color.

Scaling to the maximum does not fix it either, because one spike flattens everything below it. The bands are now quantiles of your own tenant's active days, rounded to readable numbers, so the grid answers the question it exists to answer: how does this day compare to a normal day here. It uses the full range whatever your volume looks like.

Cards or a table, on both agent lists

The agent lists — the administrator's and the user-facing one — now carry a Cards / Table toggle. The table is a dense ledger: one row per agent, click a row to expand its detail panel inline. Quarantined hosts pin their Approve and Reject actions in the row, with the rest available in the panel.

Your choice is remembered and shared across both views, deliberately. It is a preference about how you like to scan an agent list, not a setting that should differ per page.

Pending updates say which kind of late they are

A single OVERDUE badge was painting three unrelated situations identically. It now resolves into four states, and red means only one thing:

• Scheduled — waiting for its policy window.
• Due — the window is open and it is next in line.
• Waiting — the agent is offline. A two-week-old row on a dead host now reads grey instead of alarming red.
• Late — the agent is reachable and the row is past when it should have gone out.

The threshold for Late scales with position in the queue, so a thousand-agent rollout is not painted red for its first hour merely for being a thousand agents long. The lifecycle stepper also stopped marking rows as sent that had never been dispatched, which had been contradicting the pipeline's own count.

Relatedly: clicking Update now on an agent covered by a maintenance-window policy used to appear to work and then silently revert a few minutes later, with nothing shipping. Bringing an update forward left the row indistinguishable from one the planner had drifted, so the next planning pass pulled it back into the maintenance window. A forced update now survives, and the operator who forced it is credited on the row.

AI provider connections

Three fixes, one of which is data loss worth checking on.

Toggling an MCP server on or off silently erased its usage guide. The guide is the admin-authored text the model actually reads before using that server's tools — often a kilobyte or more of hand-written guidance. The enable switch sent an update that omitted the field, and the update replaces the whole record, so the guide was blanked with no warning and no way to notice until the AI started using the server badly. If you maintain usage guides on your registered servers, it is worth opening them to confirm they are intact.

Renaming an AI provider connection onto a name another connection already used answered with a bare internal error. It now tells you the name is taken. Two connections on the same model are still perfectly fine — it is only the name that has to be unique.

And the connection picker is now the same component everywhere it appears: in chat, in workflows, and on the playbooks view. Azure AI Foundry connections show their model family rather than the raw deployment name, so a connection you named for its deployment is still recognizable.

Sessions, and a Devices view

Browser Sessions is now just Sessions. The qualifier stopped being accurate once the iOS app started appearing in the same view.

Alongside it, Admin → Audit → Devices is new: the registered devices that can receive push notifications, showing who registered each one, its platform, when it was registered and last seen, and a revoke action. It sits as a sibling of Sessions and MCP Sessions rather than underneath them — a device registration is not a session, and it outlives every session made from that device.

Tenant expiry and licensed systems

Two notices can now appear at the top of the portal, and they share one compact strip rather than stacking as separate bars.

The expiry notice appears to everyone in the tenant as your subscription end date approaches. The licensed systems notice is administrator-only, since only an administrator can act on it, and appears when your onboarded systems — agents plus enabled MCP servers — exceed your licensed count. That ceiling is advisory: exceeding it warns, it does not block.

Both notices name Sales rather than your administrator, because both are commercial. The action opens a pre-filled request carrying the facts already on screen, and because a mail link is inert on machines with no mail client bound, the address is also rendered as selectable text and the whole draft can be copied to your clipboard.

Dismissing a notice hides it only while the facts stay the same. When a day passes or another system is onboarded, it comes back — silencing a four-days-left warning should not also silence the one-day-left warning.

If you have no expiry date and no system ceiling set, nothing appears. That is the default, and this release changes behavior for exactly zero existing tenants.

Two smaller ones

Exporting insights as JSON stopped at five thousand records and handed you the file with no indication that your filter had matched more — a short export that looked complete. It now pages through the whole result set, and where a genuinely enormous export is capped, it says so and gives you both numbers.

And Start Chat could end up permanently disabled with no explanation if the list of AI connections failed to load once. The failure was being treated as unimportant, which stopped being true when the button started depending on it. There is now an error with a Retry, instead of a dead button and a notice telling you to ask an administrator about a problem an administrator cannot fix.

Spacing across the portal was also quietly wrong in a large number of places, in a way that had been invisible because it had always been that way. It is now consistent.

See Dashboard, Agents, and Agent Updates for the surfaces involved.

Questions or feedback? Reach us at info@infrascout.cloud.