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.

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
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
