The short version
Garth sits alongside your engineering systems, not in the path of them. G360, GReview, GRelease and GScan read from your repositories, your work tracker, your CI and your collaboration tools. If a Garth product goes down, your developers keep committing, merging, building and releasing. What pauses is the intelligence Garth adds on top, and most of it catches up on its own once service is back.
That design choice is the foundation of our continuity approach. The rest of this page explains what we maintain around it and what we'll share with you.
What we maintain
- A written Business Continuity Plan for deployments in your VPC or on-premises, covering how the product is built, what holds state, what needs backing up, how recovery proceeds and how we validate it.
- A review of the plan at least once a year, and again after any material change to the product or after a continuity incident.
- Recovery exercises with customers in a non-production environment, so the procedure has been run before anyone needs it.
- A single agreed channel during an incident, with updates on impact, actions in progress and anything blocking recovery.
- A post-incident review for every continuity event, with corrective actions folded back into the plan.
Shared responsibility
Garth products run in Garth Cloud, in your VPC, or fully on-premises. Where the product runs decides who owns what.
In your VPC or on-premises
You run the infrastructure: compute, network, database, backups, identity and the connected systems. We're responsible for the application itself, its recovery procedures, product defects, and hands-on support while you recover. Your data never leaves your environment, and recovery doesn't depend on reaching us.
In Garth Cloud
We're responsible for the hosting infrastructure and its recovery. You remain responsible for the availability of your connected systems and for the credentials that let Garth read from them.
Product by product
G360
G360 only reads. It writes nothing back to your systems. If it's unavailable, dashboards and executive summaries pause, and the data it collects from your tools is picked up again after recovery.
GReview
GReview reviews pull requests and posts its findings back to your source-control platform. If it's unavailable, pull requests simply go without a Garth review. They aren't blocked unless you've chosen to make GReview a required check. Pull requests opened during an outage are picked up after recovery.
GRelease
GRelease grades release readiness from your work tracker, repositories and CI. If it's unavailable, that grade isn't there, but your release process and the tools behind it carry on. The picture is rebuilt from those systems once service is back.
GScan
GScan scans your repositories on a schedule and on demand. If it's unavailable, scans pause and resume on the next run. Your repositories aren't touched either way.
GKS and Garth Universe, the shared services behind these products, are covered by the same plan.
What we'll share with you
Detailed Business Continuity and Disaster Recovery documentation, including the recovery approach, backup scope, recovery targets and the responsibility split for your deployment model, is available to customers and prospective enterprise customers on request.
Ask us for the full plan and we'll send it over.