Cloudthread Y Combinator
August 23, 2022

Offsite Hackathon: Cloud Carbon Footprint Analytics

Cloudthread Engineering team hacking sustainability feature together!

Goal and Context

What better way to get to know each other better and have fun than to build something together? 

As soon as we started planning our first in person offsite, we wanted to organize a hackathon during the week. We’ve been building together remotely non-stop but we wanted to take advantage of the time together to collaborate on something new and maybe learn some lessons that we could apply when we go back to collaborating remotely. 

Ultimately, the goal of the hackathon was to:

  • Have fun
  • Collaborate in person
  • Build something related to Cloudthread’s mission

Choosing a problem to solve

We were tempted to build something that is already on our roadmap. It would already be scoped, we know our customers would want it, we know we’d be building it eventually. Ultimately, we decided this wouldn’t be as interesting as choosing a new, unique topic to dedicate ourselves to.

So what should we build?

We wanted something that:

  • the whole team cares about 
  • could have an MVP built in a day
  • is related to our mission, but not necessarily being demanded asap by our customers

Ultimately, we decided to incorporate cloud carbon footprint analytics into the Cloudthread platform!

Climate issues are something that our team members care about on a personal level, cloud carbon reduction is related to our goal of making organizations efficient in the cloud, and we are excited to help companies contribute to their sustainability goals by monitoring, understanding, and reducing greenhouse gas emissions

Problem Exploration

We needed to get educated about the space. Admittedly, part of this happened ahead of time.

The problem of climate change’s negative impact on planet earth and greenhouse gas emission contribution to climate change needs no expanding here. We were surprised to find out, however, that data centers contribute 2% of greenhouse gas emissions. While this may seem like a small number, this is equal to the emissions of the entire aviation industry. 

In March of 2022, Amazon launched AWS Carbon Footprint Tool which was met with both praise and criticism. Ultimately we had to understand this existing AWS native solution to ensure we were building something that had additive value. 

Ultimately we had to understand this existing AWS native solution to ensure we were building something that had additive value. 

There were three main criticisms from users and climate experts on the AWS carbon footprint tool:

  1. Emissions are “calculated using the GHGP market-based method”.This means that Amazon’s “renewable energy purchases” are subtracted from the actual GHG emissions. Climate scientists maintain that location-based, as opposed to market-based, is a better way to report on GHG emissions.
  2. There isn’t region level granularity. Regions are reported in an aggregated way (i.e. Europe instead of eu-west1). This inhibits users from being able to select specific data centers for workloads based on environmental impact.
  3. There is limited AWS Service coverage. The “Other” bucket of AWS’ native tool is broad and prevents users from benchmarking and tracking different AWS services effectively. 

We wanted to find a reputable, unbiased source of carbon footprint data that would allow us to improve on AWS’ limitations when it came to emissions reporting from the Cloudthread platform. 

Ultimately, we decided on using – an opensource tool and dataset that’s well regarded and explicitly addresses AWS shortcomings. It uses the GHGP location-based method, it reports at datacenter granularity (referencing the energy source of the specific grid where the datacenters are located), and it has a broader coverage of AWS services.


To align on what we were building, we discussed why, who, and what.

Why is this worth building at all?

Creating this feature would allow software companies to understand, monitor, and ideally reduce their greenhouse gas emissions by making (relatively) environmentally friendly infrastructure decisions. 

  • An application or batch job could be run in a region with lower emissions.
  • Different application architectures could be benchmarked to evaluate which mix of AWS Services yields the most environmentally efficient option. 
  • Regulatory reporting on emissions (already exists in Europe) could be done quickly and conveniently.

Who would use it if we built it?

An essential question for any feature. Ultimately given time constraints we built a single portal but we discussed that potential consumers of GHG emission data could be Sustainability Teams, Finance, Legal, and Engineering. 

What would it look like?

Ultimately we decided to build this as a feature within the Cloudthread platform. This would allow Cloudthread customers to access the analytics from a familiar interface, allow us to recycle existing front end components, and allow the new dataset to use Cloudthread’s existing reporting/alerting infrastructure. 


After creating conviction and alignment, time to build :) 

We split into teams to start setting up the data pipeline and designing the UX/UI.

At a high level, we were using one existing dataset we were very familiar with (AWS resources and costs) and a second new data source: the CO2e estimates from If you’re curious, they detail their methodology here.

Given that we decided to build the feature on the Cloudthread platform, we were going to integrate into our existing tech stack. 

It was a long day and we of course ran into various issues along the way (part of the fun!) but ultimately we pulled together an MVP and presentation we were proud to share with our judges the following morning.

The result was a new Sustainability section on the Cloudthread platform with two sections: 1) a dashboard dedicated to giving a summary with breakdowns and 2) an overview chart designed to explore more in depth with custom filters. This final result:

  • Reports location-based Scope 2 emissions
  • Has regional granularity
  • Has broad AWS service coverage


We invited judges from our network with expertise in the tech, investing, and climate domain to present the results of the hackathon to. This was crucial - it motivated the team to take the project seriously, anchored us in delivering something concrete to show, and most importantly provided incredibly valuable feedback for future development directions.

Huge thanks to the judges for their time and valuable contribution! Alexander Kabirov, Daniil Bargman, Eva Perrett, Ilia Shabrov, and Marijn Goemans.

Everyone on the team got a chance to discuss their contributions and challenges during the hackathon, we received insights on the problem space, and we got a long list of great ideas for further development of the feature.

We left this session energized about getting Cloudthread Sustainability into the world and the impact it could have.

Next Steps

It’s amazing what a motivated team with a singular focus can do.

We’re excited to roll out the prototype that we built to production, get feedback from our customers, and expand on the Sustainability functionality over time. 

If you’re interested in getting beta access before we make it publicly available, ping us by email at or by using the chat icon bottom right. 

PS: If you think it’s ironic that we built a sustainability feature during an offsite that we all flew to participate in, we agree. For all air travel at Cloudthread, including flights to this offsite, we offset our flights through Project Wren.

Make cloud costs a first class metric for your engineering organization.
Copyright © 2024 CloudThread Inc.
All rights reserved.
Copyright © 2024 CloudThread Inc. All rights reserved