Orphan clusters

A segment with no policy coverage is reachable by nobody. The connector group serving it is using its CPU for nothing.

This report groups orphans by their segment group so you can see the scope: one stray segment in a healthy group is a leftover; an entire group orphaned is something nobody is touching.

Endpoint

GET /api/v1/analytics/orphan-clusters

Returns

type OrphanCluster struct {
    SegmentGroupID   string
    SegmentGroupName string
    FullyOrphaned    bool        // true if every segment in the group is orphaned
    OrphanSegments   []NamedRef
    ConnectorGroups  []NamedRef  // groups still serving the orphans
}

Sorted by orphan count descending. The biggest dead clusters surface first.

How

1. Start from Index.OrphanSegments (segments with no policy coverage, computed during index build).
2. Group by seg.SegmentGroupID.
3. For each cluster, walk server groups; any server group that lists one of the orphan segments contributes its AppConnectorGroups to the ConnectorGroups field.
4. Mark FullyOrphaned = true if every segment in the segment group is orphaned (i.e. len(orphans) == len(group.Applications)).

Use it for

• Cleanup work. Fully-orphaned clusters are usually projects that died without taking their infrastructure with them. Remove the segment group, the segments, and possibly the connector binding.
• Connector right-sizing. If a connector group only serves orphan clusters, the connector group is also dead weight.
• Detecting stale staging. Old “test” segment groups full of orphans hint at staging environments that were never cleaned up.

Edge cases

• A segment with SegmentGroupID = "" (somehow) is excluded - the cluster view needs a parent. The flat OrphanReport[] from /api/v1/reports/orphans lists those.
• Connector groups that serve mixed clusters (some live, some orphan segments in the same server group) still appear in ConnectorGroups. This is intentional - the load is real even if not all of it is wasted.