Infrastructure Groups
Group sites that share hosting, CDN/WAF, DNS, origin, or other infrastructure.
Infrastructure Groups
Infrastructure groups help agencies see when several sites may share the same underlying cause. A group can represent a server, hosting account, CDN/WAF, DNS provider, origin, or other shared dependency.
When to create a group
- Several sites are on the same hosting account, server, GridPane/Vultr server, Cloudflare account, WAF, DNS provider, or origin.
- Several sites begin showing review work at the same time and you want to track whether one shared layer is involved.
- Monitoring evidence is overdue for multiple sites and you suspect a firewall, WAF, server, DNS, CDN, or probe allowlist problem.
How to manage groups
- Open All Sites.
- Review the Infrastructure groups section.
- Use Create group from shown sites when the visible sites share infrastructure.
- Use Assign shown sites to move visible sites into an existing group.
- Use Edit group details to rename or clarify a group label.
Shared-signal detection
MetricPoints looks for the same kind of problem on more than one site in the group — for example the same timeout class, the same HTTP 5xx class, or the same latency regression. Unrelated review work on two sites does not count as a shared issue. A matching cluster is recorded immediately as evidence. A critical group alert is sent only if that cluster is still present after a short confirmation window, so a recovered blip stays in history without paging anyone.
Alert routing
Infrastructure groups can have their own alert profile, but grouping sites does not change notifications by itself. A site uses the most specific route available: site override first, then infrastructure group route, then the agency default route when configured. Sites can return to inherited routing by clearing the site override. A confirmed shared-infrastructure incident pages the group route once and lists the affected sites.
Team notes
Add team-only notes to a site, incident, or infrastructure group when human context will help the next person reviewing it. Notes show their author and time, can be pinned, and remain available after an incident is archived. Infrastructure notes stay with the shared group and are visible from its member sites. Notes do not change health, monitoring, ownership, or alerts, and should never contain passwords, API keys, private credentials, or personal customer data.
Completing a review
Choose “I'll review this” to take responsibility for an incident. Once you have checked the evidence, choose “Complete review,” record whether the condition is expected or has been addressed, and explain why. The explanation is saved as an incident note and remains visible in archived history. “Stop reviewing” releases the assignment for another teammate; it does not close the notice. MetricPoints continues to collect check results after a review is completed. Reopen the notice if the decision needs another look.
Possible shared issue
This label means multiple sites in a visible cluster share the same signal class, such as timeouts or sustained latency. It is a clue with a stored hypothesis, not a final diagnosis. A recovered blip remains in history. An alert is sent only when the shared pattern is still happening.