Alerts built on the same query language you'd write by hand

A monitor is a gcQL query plus a threshold. The same language that builds a dashboard widget defines what a monitor watches for, so there's no separate alerting syntax to learn once you already know how to ask groundcover a question.

The Monitor Wizard shows a live preview of which Notification Routes will fire based on your current configuration, before you save anything. Pongo2 templating lets issue titles and summaries pull in dynamic values like {{ labels.namespace }} or {{ values }}, with autocomplete so you're not cross-referencing docs to remember the variable name. End-to-end testing simulates an issue against your monitor so you can confirm the right routes and the right connected apps receive it, before it's live against real data.

The Slack Connector routes monitor notifications to the right channel and lets the groundcover agent investigate with the full thread as context, so an alert in Slack isn't a dead end. The Linear Connector turns a firing issue into a ticket automatically, and feeds Linear's own history back into root cause analysis. The same issue view that lives in the product now shows up in Slack when a monitor fires, so investigating doesn't require a tab switch.

Monitor health now surfaces directly in the drawer, and a No Data state comes with a reason and its own routing, instead of silence that looks the same as "everything's fine." The Monitor List page is the filterable hub for every monitor you run: name, creation date, live issue count, and firing status at a glance, with saved team views and facets so a large monitor library doesn't become its own investigation.

Monitors are now a first-class typed Terraform resource instead of a YAML blob, so teams that manage their observability configuration as infrastructure can version, review, and roll out monitors the same way they do everything else.