The Monthly Showcase

Look away from groundcover for two weeks and you come back to several new products. That's what this July felt like. We ran our first customer showcase this month, walked through everything that shipped, and the reaction in the room was the one we were after: that was all shipped in a month of work?

‍

So here's the recap for everyone who wasn't there. One thread runs through all of it. The agent got a lot more capable, and almost everything else we shipped exists to feed it better context — or to make the thing it hands back to you easier to read. More context in, better observability out. Let's get into it.

Agent Mode, everywhere you already work

The assumption baked into most observability agents is that enough telemetry will find the problem. Telemetry is half the picture. The other half including what a cluster actually represents, who owns a service, a conversation in Slack, architectural docs in Notion lives in the tools around your stack, not inside it.

‍

groundcover now ships first-class connectors for the apps your team already lives in: Slack, Linear, Cursor Cloud Agents, Pylon,  Notion and more. You could always wire these up over remote MCP. However, first-class connectors eliminate the frustration of chasing API access through an admin, finding keys etc. You connect org-wide with OAuth in a single click, and the connector is live across your platform. OpenAI Codex, Claude Managed Agents, Jira, and GitHub Copilot are next. Through showing you a list of first class connectors in one place, we also created the Connectors page to inspire you to expand the groundcover’s tool access and start thinking about custom observability agents you want to create. 

‍

Connecting is only half of it. From a connector's settings you decide what it's allowed to do: toggle individual tool calls off, force certain actions behind an approval gate, or block them outright. The agent gets intentional access. The agent also has the same RBAC, same budget the admins set for your user. It can only see what you can see, and it can't spend what you can't.

‍

Here's what that unlocks in practice. A monitor fires and drops an alert into Slack. You tag @groundcover in the thread and ask it to investigate, right there alongside whoever else is watching. It works the incident with your full-fidelity telemetry, pulls in traces and logs, and when the failure points at real user impact you can ask it to surface the RUM session so you can see exactly what the user hit. Ask for the 5xx rate across the three affected services and it builds the table and drops it in the thread. Nobody goes hunting.

‍

Then the natural next step: a ticket. Ask it to open one in Linear and, for example, the guardrail stops the agent and asks you to approve the save_issue call. Approve, and the ticket lands with the full root cause attached.

‍

You can wrap that entire sequence into a groundcover skill and call it from the app or from Slack. Either way it's the same agent with the same memory: run an investigation in the app, ask about it later from Slack, and it already knows the ticket exists and who filed it. We're also shipping the plumbing for teams that want to manage this like infrastructure — Skills as Code exposes skills through the SDK and Terraform with a new groundcover_skill resource, query guardrails keep signal payloads from overwhelming the agent, and you can point Agent Mode straight at the Anthropic API.

Monitors and Issues

We rebuilt the Monitor Issues page to give you a single place to see everything that happened, with the issue's data kept as granular as it actually was at the moment. The new layout follows how you read an incident. You see the timeline of when the monitor fired, went normal, or was silenced, a dedicated section for the active silences affecting it, and the full notification history so you can see what was sent and what wasn't.

‍

Around it, we made monitor health visible so failures stop happening quietly. The drawer now tracks notification delivery — successful sends versus failures — and surfaces evaluation errors with real traces, error types, and timestamps. No Data got a deadman alert that tells you why a signal stopped instead of just reporting silence, and you can route those No Data issues so someone actually catches them when telemetry drops.

‍

One that a lot of you asked for: AWS metrics that arrive late no longer throw false alerts. We auto-detect AWS metrics and set an evaluation delay for them, with an offset knob so you're always evaluating against accurate data. And the monitors and issues views themselves got modern filtering, faceted navigation, customizable tables, and saved team views, so you stop rebuilding the same search every morning.

Dashboards and Visualizations

There's a story going around that dashboards are on their way out — that agents got so good you'll just ask a question and the wall of charts becomes a relic. Our own backlog says otherwise. The requests for more control and more polish keep coming, and the reason is that dashboards and agents feed each other. The agent reads your dashboards to understand what "normal" looks like; you ask the agent to build the next one. So we leaned in.

‍

Creating a dashboard is now an agent-first action. For example, ask it to  "check the health of each of our workloads, focus on these areas" and the agent stands it up. New this month is the treemap, a widget for seeing at a glance which workloads or services dominate a dataset without scrolling a table.

‍

The bigger structural change is variables. Real infrastructure is a pile of tools that all name the same concept differently — one source says cluster, another says clusterName, a third has whatever convention you migrated off of. We rebuilt variables around custom mapping so a single $cluster variable can point at whatever each source calls that field, resolved per query. One templated dashboard works across every source instead of forcing a copy per source — which is exactly the mess you're living in right after a Datadog migration. Variables reach across entities, issues, and APM too, and the setup flow suggests good ones so you're not staring at a blank slate.

‍

Then the long tail of readability, most of it requested directly by users in the last couple of weeks: add any query output from the Explore page straight to a dashboard, color a stat tile by condition so it turns red the moment it crosses your line, apply thresholds to time series, sort legends as tables with per-series stats, set decimal precision so a tiny value shows as <0.01 instead of rounding to a misleading zero, and give axes their own units and titles. Widgets and sections take descriptions now too. Small stuff individually. Together it's the difference between a dashboard you fight to read and one that just tells you what's happening.

Storage and Retention Management

You can now manage your own data retention from inside the product instead of filing a support request — and it fits the BYOC, per-node model, so this is real cost control, not a toggle. Set the default retention per data type (Monitor Issues and APM are covered now, more coming), define when data transitions to cold storage, and set retention holds when you need to keep something past the default.

‍

Underneath that, index tiers make queries against retained data fast: scope a query to a specific tier and it outperforms a broad time-range scan. And a new ingestion data source gives you the picture of where your data is actually coming from — break it down by namespace or source to see who's driving load, which is the first thing you want when a bill moves and you don't know why.

AWS Cost

This is the integration a lot of you have asked for: your AWS cost, sitting alongside your observability data as a first-class data source. Query it in Data Explorer next to metrics, logs, and traces. Build monitors and alerts on budget breaches. Ask the agent a cost question in plain language and get an answer.

‍

Setup runs through a wizard. Point it at a new or existing Cost and Usage report and bucket, add labels if you want to tag a team, and run the generated CloudFormation — or Terraform — against your AWS account. Paste back the ARN, give groundcover read access, and data starts landing within about a day. We ship an AWS Cost Overview dashboard to start: spend by service as a treemap, service mix over time, and cost by region. The real payoff is seeing spend and observability data in one place. When your S3 bill ticks up and your ingestion volume climbs the same week, the agent can connect the two and tell you which workload started emitting more, when, and what to trim.

Dashboard Catalog

Last one, and it ties the rest together. The new Dashboard Catalog is a set of curated, prebuilt dashboards you can preview against live data before you install anything, so a new teammate starts from best practices instead of a blank canvas. It's grouped by integration: K8s, Hosts & VMs, AWS (including DynamoDB and ElastiCache), Databases, Messaging, CI/CD, AI & LLM, and Platform & Usage.

‍

Catalog dashboards are managed by groundcover, which means we keep improving them and those improvements show up for you — carefully, without deleting the widgets you rely on. Want to change one? Hit customize and you get an editable copy that's yours to reshape, while the managed original keeps updating on its own track.

‍

The catalog is also encoded expertise the agent can lean on. The Ingestion Overview dashboard already frames who's driving your ingestion; the Cost Footprint dashboard already frames where spend goes. Each one is a curated map of what "normal" and "worth looking at" mean for a domain. They provide the exactly the context the agent would otherwise rebuild from scratch on every investigation. The dashboards supply the framing, the agent turns it into something actionable, and neither replaces the other.

That's July

Agent Mode reaching into the tools you already use, an issues experience that finally shows the whole picture, dashboards that got easier to read and easier to build, retention you control, AWS cost as real telemetry, and a catalog to start from. It all points the same direction: feed the agent your context, and it hands you sharper observability back in the places you already work.

‍

If you want to go deeper on any of this, it's all on the What's New page. See you at next month's Buzz.

‍