Docs / Infrastructure
Monitoring
One place to see monitors, alerts and incidents across Grafana, Better Stack and Google Cloud.
The Monitoring view brings the health signals from your connected observability tools into one picture. You see monitors, heartbeats, alert rules and incidents in one place instead of switching between consoles.
What shows up here
- Monitors and heartbeats: uptime and liveness checks.
- Alert rules: what is set to fire, and what is firing now.
- Incidents: active and recent.
The view reads from three providers: Grafana, Better Stack and Google Cloud. Every row links to its source provider for the full detail. You can filter by provider and status.
Other providers have their own pages instead. AWS shows CloudWatch alarms, metrics and log groups under its account. Uptime Kuma shows its monitors on its own page.
Acting on a row
Each row has a menu with these actions:
- Watch with Agent: hand the monitor or alert rule to the agent as a Watch. You choose where the agent reports when it fires. See Triggers and automation.
- Open in provider: open the rule in the provider's own console.
- Delete: remove the rule in the provider itself, where the provider allows it. This can't be undone.
To watch several rows at once, select them and click Watch selected. Pangea manages them together as one group, up to 50 items. Split larger selections into separate groups.
Where a Watch reports
When you start a Watch, Pangea asks Where should Pangea report?
| Destination | What happens |
|---|---|
| Pangea | The agent investigates and keeps the findings in Pangea. |
| Slack DM | The agent reports to you privately in Slack. Link your Slack identity first. |
| Slack channel | The agent posts an incident message in the channel that people can reply to. |
Slack destinations need the Slack connector. For a channel, invite the Pangea bot to it first.
Creating monitors
The Monitoring view does not create monitors. Create one in the provider's own console, or ask the agent. The agent reviews the target, monitor type, interval and destination before it creates one. Plans apply to significant cloud work, not to every monitor action.
During an incident, start here to see everything that is firing. Then move to Grafana or the agent to chase the root cause.
Check freshness and delivery
- Each provider is read separately, and one can fail while the others load. Check any "unreachable" notice before you treat the view as complete.
- A new monitor can take a refresh cycle to appear.
- A monitor in this list proves it is configured. It does not prove that alerts reach a person. Check the provider's outgoing webhook and destination separately.
- For resources with no public endpoint, use the cluster's own metrics and alerting. Don't add an external HTTP probe for every Deployment or Node. Ask the agent to inspect the existing data sources and monitoring first.