Destinations
Destinations are external integrations you configure to receive notifications from or interact with groundcover
Destinations was previously called Connected Apps and lived under Settings → Connected Apps. The page has moved to Integrations → Destinations and the feature is now called Destinations throughout groundcover. All existing integrations carry over — only the page name and location changed.
This capability is only available to BYOC deployments. Check out our pricing page for more information about subscription plans and the available deployment modes.
Admin permissions are required to open the Destinations page and to create, edit, test, or delete Destinations. Editors and Readers cannot access the Destinations page directly, but they can see Destination references that are already attached to Notification Routes and monitors (e.g., when viewing or editing a route or monitor's notification settings).
Supported Destination Types
Send notifications to selected Slack channels via the groundcover Slack App (supports per-rule channels)
Create and keep Linear issues synchronized with groundcover monitor issues
Send notifications to a single Slack channel via an incoming webhook URL
Send notifications to a PagerDuty service directory using a Routing Key
Send notifications to incident.io using an Alert Event URL
Send notifications to Rootly using a Generic Webhook with an API Key
Send notifications to any webhook, including authentication, headers, and payload
Send notifications to an OpsGenie team using an Integration API Key
Add a Destination
Go to Integrations → Destinations
Click the destination type you want to add
Fill in the required fields:
Integration Name: A friendly name for this connection (e.g.,
prod-alerts-channel)Integration Details: The URL, Secret, Key, etc..
Click Save
The Slack App is a special case — selecting it from the Destinations page opens the same setup wizard that lives under Integrations → Connectors → Org Connectors → Slack, and both entry points manage the same underlying resource. The wizard requires extra one-time setup in Slack (creating an app from a manifest, generating an App-Level Token, and OAuth authorization). See the Slack connector guide for the full walkthrough.
Managing Destinations
The Destinations page shows all your configured integrations in a table with:
Name: The integration name you assigned
Type: The destination type (e.g., Slack Webhook)
Creator: Who set it up
Used By: Notification Routes and Monitors that reference this destination (each reference is labeled either
notification_routeormonitor)Created at: When it was added
Edit or Delete
Hover over any row to reveal the Edit and Delete buttons.
A Destination being used by Notification Routes or Monitors cannot be deleted. Check the "Used By" column is empty (no notification routes and no monitors) before attempting to delete.
For Developers
The product surface uses Destinations, but the platform APIs, SDKs, and Terraform provider still use the original connected-apps / connected_app naming for backward compatibility. Existing automations continue to work unchanged — no migration is required.
REST API base path
/api/connected-apps/v1 (e.g., POST /api/connected-apps/v1, POST /api/connected-apps/v1/list, GET /api/connected-apps/v1/{id}, PUT /api/connected-apps/v1/{id}, DELETE /api/connected-apps/v1/{id}, POST /api/connected-apps/v1/test)
Response field names
connectedApps, used_by[].type (notification_route / monitor)
Monitor YAML field names
notificationSettings.connectedApps, notificationSettings.connectedAppParams (see Monitor YAML structure)
Terraform resource
groundcover_connected_app — see groundcover Terraform Provider
The rename is a UI-only change; no API endpoint, SDK call, or Terraform resource was renamed.
Next Steps
After setting up your destinations, create Notification Routes and Monitors to start routing issues to them.
Last updated