GraphOS Router Support Tool
OverviewGetting Started
Modes

Local Mode

GuideReference

Job Mode

GuideReferenceSupport Bundle Storage and Retrieval
Data CollectedCollecting Metrics
Products
Apollo GraphOS PlatformManage, observe, and scale your graph.GraphOS Agent ServicesPreviewGovern how agents access your graph.Apollo ConnectorsConnect REST APIs to your graph declaratively.Apollo FederationFederate multiple subgraphs into a single supergraph.Rover CLIInteract with your graph from the command line.Apollo RouterRun and configure your graph gateway.Apollo OperatorDeploy and manage Apollo Router on Kubernetes.
Open source
Apollo Client (Web)Simplify GraphQL data management in web apps.Apollo iOSSwift-first GraphQL client for iOS.Apollo KotlinKotlin-first GraphQL client for Android and JVM.Apollo ServerBuild GraphQL servers with Node.js.Apollo MCP ServerExpose GraphQL tools to AI agents with MCP.IDE SupportEnhance your development workflow with IDE support.GraphOS Router Support ToolDiagnose and troubleshoot your GraphOS Router.
Resources

Getting Started

Choose how you'll run the GraphOS Router Support Tool

This guide steps through generating your own on-demand support bundle collection from any Kubernetes-hosted router deployment.

Generating a support bundle is done through a single Helm chart, router-diagnostics-chart, with a mode value controlling how collection runs. Both modes collect the same information, only how and where the tool runs and where the bundle lands differ.

There are two independent things you need to determine before installing anything:

  1. Which mode fits your access? This changes the command you run, what gets installed in your cluster, and what permissions are required.

  2. How was the router deployed? This changes a couple of chart values, regardless of which mode you picked.

1. Choose a mode

mode: localmode: job
Who runs collectionYou, from your own machine, with your own kubectl accessA Kubernetes Job, in-cluster, using its own ServiceAccount
What gets installedSpec ConfigMap onlySpec ConfigMap + Job + ServiceAccount/RBAC (namespace-scoped and cluster-scoped)
Where the bundle landsYour current directoryS3 (or S3-compatible), GCS, or a bare HTTP(S) endpoint you configure. For more information, go to Bundle storage and retrieval
Use whenYou have kubectl access to productionYour kubectl access is restricted and a platform team runs collection on your behalf

Not sure which applies? If you can run kubectl get pods against production yourself right now, you want mode: local. If someone else on a platform team has to do that for you, you want mode: job.

2. Confirm how the router was deployed

Whichever mode you picked, the chart needs to know how to find your router. That depends on how it was deployed:

DeploymentWhat you supplyWhy
Official Apollo router Helm chartnamespace onlyThe chart's collectors target your router by its standard app.kubernetes.io/name=router label and know the ConfigMap name and ports it uses
Raw manifests / custom deploymentnamespace, selector, configMapName, metricsPort (if not 9090)None of the official chart's conventions apply, so nothing about your router's location or configuration can be assumed

Both the local mode and job mode pages show the install command for each case.

Deploying the router via the Apollo Operator? That path isn't supported yet.

Full reference

This page has covered the values you need to get a first bundle collected. For the complete set of chart values, as well as exactly what RBAC each mode grants and why, go to: