Frequently asked questions about Flux
Answers to all your Flux questions, all in one place.
What Flux is
It analyzes real code, commits, and pull requests, not ticket data or manual reports, to give engineering leaders ground-truth visibility into velocity, team dynamics, and code quality across their entire codebase.
Flux is built for engineering leaders—VPs of Engineering, heads of engineering, directors, and managers—who need objective visibility into how work is actually happening across the codebase. It’s designed for GitHub Cloud organizations with 50 or more engineers: teams where a leader can no longer personally track everything and needs estate-wide intelligence to lead effectively.
Tech leads and senior ICs also use Flux to understand code health, hotspots, and team dynamics without adding reporting overhead.
Flux is built for engineering leaders but used across the organization. Leaders track velocity, focus, and risk across teams and explain tradeoffs to executives. Managers and tech leads see how teams actually work in the code and manage technical debt. Senior ICs check code health and hotspots in the areas they own, with no added reporting.
Flux gives you ground-truth visibility into how work actually happens in your codebase, not what tickets or status reports claim, so you can act early, before delivery friction, hidden risk, or shadow work shows up in an incident or a missed deadline. Specifically, Flux helps you separate feature delivery from maintenance and rework using objective, code-derived metrics including DORA, spot emerging risk in PR size and churn before it surfaces in sprint reviews or escalations, expose shadow work that never makes it into tickets, connect incidents back to hotspots and accumulated technical debt, and explain progress and risk to executives using code-first evidence.
How Flux compares to other tools
Snyk and CodeRabbit catch and fix issues in individual code changes. Flux sits above them, showing patterns across your entire codebase and teams: where risk is accumulating, how AI is changing delivery, and how quality work maps to features, maintenance, and technical debt.
Flux doesn’t replace your scanners or AI code review. It gives you the system-level view those tools can’t provide.
AI code review tools operate at the change level, catching problems in individual pull requests. Flux operates at the system level, surfacing patterns in risk, architecture, and quality across all repos and teams, answering the leadership questions PR-level tools can’t: where AI is helping or hurting velocity, where technical debt is slowing delivery, and how to explain this quarter’s progress to the board.
No. Flux complements Jira by showing what actually happened in the code, not just what tickets say. Jira remains your system of record for intent and status. Flux adds ground-truth visibility that ticket data can’t provide.
Leaders use Flux to validate plans, spot hidden work, and connect incidents and roadmap outcomes back to the codebase, while tickets stay in place for coordination and planning.
Flux is purpose-built for GitHub Cloud organizations. If your engineering estate runs on GitHub Cloud with 50 or more engineers, Flux is designed for you. Support for additional source control platforms is not currently planned.
Yes. Flux tracks DORA metrics (deployment frequency, lead time for changes, change failure rate, and time to restore) derived directly from code and PR activity, without requiring manual input or ticket instrumentation. Because Flux uses code-first data, DORA metrics in Flux reflect what actually happened, not what was reported.
Setup and integrations
Flux is a cloud SaaS platform. There’s nothing to install on developer machines. To get started, you connect your GitHub Cloud repositories and configure which repos and teams you want analyzed. No changes to your existing ticketing or delivery processes are required.
Most customers connect their repositories and start seeing classified data within minutes. Flux backfills historical commits and PRs automatically, so you’re not starting from a blank slate.
No. Flux doesn’t require agents on developer machines or changes to your CI/CD pipeline. You connect your GitHub Cloud repositories and identity provider; Flux handles analysis from its own infrastructure. Setup overhead for your engineering team is minimal.
Flux is built for estate-wide analysis and supports monorepos, multi-repo estates, and selective inclusion or exclusion of specific repositories. It’s designed to scale across hundreds or thousands of repositories, including large, complex environments where code volume and change velocity are high.
Yes. Flux’s role-based access model lets you control which repositories are connected and what each user can see, so you can scope views by team and align access with your org structure and privacy requirements.
Yes. Request a demo and we’ll walk you through the platform using real engineering data, including work classification, leadership views, and risk signals, so you can evaluate the experience before connecting your own repositories.
Request a demo
Once your repositories are connected and users authenticated, Flux automatically backfills historical pull requests and commits and begins generating insights. No ticket hygiene, no new processes, no waiting for data to accumulate. Most customers see meaningful code-level signals as soon as initial indexing completes.
Security, privacy, and compliance
Flux runs on Google Cloud Platform with encryption in transit and at rest, per-customer data isolation, strict access controls, and audit logging. Your source code is treated as critical IP. It’s used only to generate your insights and support your team, and is never sold or shared with third parties beyond essential infrastructure providers like Google Cloud Platform.
Flux is designed with SOC 2 and ISO 27001 requirements in mind. The security architecture and controls already follow those frameworks; formal certification is actively in progress as the platform scales.
No. Your code is not used to train shared or third-party LLMs. Flux uses Gemini via Google Cloud’s Vertex AI, and Google’s data governance terms prevent customer data from being used to train shared models.
Flux may use your data to improve work classification and models strictly within your tenant. Insights and models are never shared across customers.
Flux uses Gemini via Google Cloud Platform’s Vertex AI. Customer code, prompts, and derived metadata are sent to the model only as needed to generate your insights. The underlying model is not fine-tuned on your data.
BYO-LLM support is on the roadmap. The current architecture is built around secure, server-side LLM usage via Google Cloud Platform’s data governance model. Any model integration will maintain strict tenant isolation and enterprise-grade data governance.
Value, outcomes, and ROI
Flux backfills historical commits and pull requests automatically, so signals appear quickly with no data-accumulation wait. In the first 90 days, most customers get a clear work-type breakdown (feature vs. maintenance and technical debt, from code, not ticket labels), early velocity warning signals in PR patterns and churn before they become incidents, executive-ready code-first evidence for board conversations, and a prioritized risk view for refactor and debt-paydown targeting.
AI has increased the speed, volume, and complexity of code changes while making visibility into that code harder. Tickets capture even less of the real work, and PR-level AI reviewers don’t show systemic patterns across your estate. Flux is built for AI-accelerated engineering: code-first visibility at the speed your teams are shipping, so you can see how AI is changing velocity and quality, and bring that evidence to executive conversations.
Flux derives signals directly from code, commits, and pull request metadata, which eliminates the human bias that skews manual reporting. The platform is designed to incorporate your feedback and refine categorization (for example, feature vs. refactor vs. maintenance) over time, always within your tenant boundary.
The more you use Flux, the more precisely it reflects how your organization actually works.
Pricing reflects engineering org scale and repository footprint, not per-ticket volume or per-seat counts. For details and to find the right fit for your team, talk to us.