Saved views let you capture a specific combination of filters, time ranges, and layout choices under a name, then restore that exact context in a single click. Instead of recreating the same query every time you open the dashboard, you land directly where the useful signal is. For teams that monitor AI agents daily, this compounds quickly: the time saved on navigation frees attention for the analysis that actually matters. For the underlying analytics surfaces that saved views sit on top of, see observability for AI agents: logs, metrics, and traces.
The hidden cost of repetitive setup
Most observability tools give you powerful filtering capabilities. Fewer make it easy to return to a filter combination you've used a dozen times before. The result is a familiar pattern: an operator opens the analytics page, selects the same agent, the same time window, and the same tab they checked this morning. The ritual takes thirty seconds. Multiplied across a team investigating multiple agents in parallel, that overhead quietly accumulates.
It's not a dramatic failure — no single instance is painful — but it is friction that compounds. More importantly, that friction discourages the kind of exploratory monitoring that catches problems early. When restoring a useful view takes work, operators tend to default to whatever view loaded last, rather than switching to check a different agent or a different time horizon.
What a saved view stores
A saved view is essentially a named bookmark for your current dashboard state. The configuration it captures can include the view type (which section of the interface you're looking at), the active time range, and the specific tab or breakdown you have selected. When you apply a saved view later, the interface restores all of those dimensions at once.
This is straightforward in principle but requires a few design choices that matter in practice.
Named, not numbered. Views stored under arbitrary identifiers are hard to manage when you accumulate more than a handful. Meaningful names — "Morning agent health check", "High-cost connections last 7 days", "Failed tasks this week" — communicate intent to anyone on the team who glances at the list.
Scoped to the owner. A view that works for one person's investigation may be irrelevant or confusing to another. Keeping views private by default prevents the list from becoming a shared dumping ground that everyone has to scroll past. Each operator maintains their own collection.
Bounded in size. View configurations can grow if the underlying state is complex. Imposing a reasonable maximum on the stored configuration keeps the system predictable and prevents edge cases where a malformed configuration causes rendering problems.
Where saved views fit in an operations workflow
Consider the difference between two approaches to a routine morning check.
In the first approach, an operator opens the analytics dashboard, selects "last 24 hours", navigates to the cost breakdown tab, and filters to a specific agent tier. Five minutes into the working day, they've spent two minutes on setup.
In the second approach, they open the dashboard, select "Morning cost overview" from the saved views dropdown, and the same configuration loads immediately. They're looking at relevant data within seconds.
The second workflow compounds positively. Because switching contexts is cheap, operators check more things. Because they're not rebuilding filters from memory, they make fewer mistakes in setup. Because views are named, teammates can compare notes using shared vocabulary — "check the high-cost connections view" is more precise than "go to analytics and filter by...".
Investigating with context
One of the most useful patterns for saved views is supporting structured investigation. When an alert fires, the operator who picks it up often needs to look at several different angles before they understand what's happening: overall task throughput, then cost breakdown, then specific connection behavior, then recent audit events. For a broader look at the analytics surfaces that saved views sit on top of, see advanced analytics for AI operations.
Saved views can encode each of those angles as a named configuration. Rather than remembering which filters you need for each step of the investigation, you've defined them in advance and named them clearly. An investigation that would otherwise require rebuilding context at each step becomes a sequence of one-click transitions between pre-defined views.
This is particularly valuable for teams where not everyone has the same depth of familiarity with the filtering interface. A senior operator can define the views that matter most, and the rest of the team benefits from that knowledge without having to learn the interface from scratch.
Managing your view library
A collection of saved views is only useful if it stays navigable. A few practices help.
Audit your views periodically. A view that made sense during an incident last quarter may no longer correspond to anything relevant. Deleting stale views keeps the list useful. If your team uses global search across your AI estate, saved views and search complement each other — search for an ad-hoc investigation, save a view once the right filter combination proves its value.
Name by purpose, not by date. "August investigation" becomes meaningless quickly. "Guardrail violations by agent" stays useful indefinitely.
Distinguish between views you reach for daily and those you keep for reference. Some views are part of your regular routine; others are documentation of an investigation you might want to revisit. Naming conventions can help separate them.
Create views before you need them. The best time to define a view for a scenario you care about is when you're already in the right state, not when an alert is firing and you're under pressure to configure filters correctly.
Praesidia's approach to saved views
Praesidia's saved views feature is available from the analytics dashboard, where a dropdown lets you save the current configuration, apply a saved view, or delete one you no longer need. The view captures the active view type, time range, and tab selection, so applying it restores the complete context rather than just one dimension.
Views are scoped to the individual user within an organization — each operator maintains their own collection, private to them. This keeps the saved view list relevant to the person using it without views from one team member cluttering another's workspace. The underlying configuration is stored as structured data attached to your account, so your views persist across sessions and devices.
For teams that want more systematic management, a dedicated view management interface lets you create, edit, rename, and delete saved views across your full collection. This is useful when you want to do housekeeping on your views without being in the middle of an investigation — you can review what you have, remove outdated configurations, and create new ones with meaningful names before you need them. Saved views complement the broader operations dashboard for your AI estate, which provides the top-level health and activity picture that individual views drill into.
Common questions
How many saved views can I create? There is no documented hard limit on the number of views per user, but each view's stored configuration has a size cap to keep the system predictable. In practice, a typical operations team will accumulate views in the tens, not hundreds, before the list itself becomes harder to navigate than the filters it's replacing.
Are saved views shared across my team? Each saved view is private to the user who created it within an organization. They are not visible to other members of your team. This keeps your view list relevant to your own workflows. If your team wants to standardize on particular views, the convention is to document the filter configuration so others can recreate it, rather than sharing views directly.
Can I use saved views for alert-driven investigation workflows? Yes, and this is one of the most effective ways to use them. Define a view that corresponds to each investigation step you commonly perform — overall health, cost breakdown, specific agent behavior — and name them clearly. When an alert fires, your investigation workflow becomes a sequence of applying pre-defined views rather than reconstructing filter state under pressure. For the real-time event stream that drives those alert triggers, see real-time events over WebSocket.
Saved views are a small feature with a compounding return. The more consistently your team uses them, the faster investigations become, and the more confidently operators can switch between different angles on the same data.