Configure monitoring / Infrastructure Groups
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. A site can belong to several groups, including two servers at the same time.
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 Add shown sites to a group to add another membership while retaining existing memberships.
- 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
Each site selects one group under Settings → Infrastructure → Inherit site alerts from. Site overrides take priority, followed by that selected group’s configured route, then site defaults. The first membership selects the initial alert source; adding more groups does not change it. Settings are not merged across groups. Choose another source or site defaults before removing the selected membership. In the Alerts tab, apply a profile to any member group without changing the site’s source. A shared-infrastructure incident uses its own group’s settings, independently of the lead site’s override, and lists affected sites. Separate correlated incidents can still notify separately; cross-incident notification coalescing is not guaranteed.
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
An owner or admin can choose “Dismiss” to remove a notice from active review immediately without taking ownership or completing a review. Dismissed notices remain in archived history and can be restored with “Unarchive.” Dismissing a suggested relationship leaves its underlying signals unchanged; the same findings stay dismissed, while new findings can create a new suggestion. 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.