Estimating the Operational Emissions (Categories O, G, and C)

Read the TCS overview of operational emissions for a primer on this category.

The approach used and why for each sub-category in operational emissions:

• Employee Devices
• Networking and Infrastructure
• Servers and Storage
• Generators
• Cloud Services
• SaaS Services
• Managed Services

Employee Devices

Note: Before this project was completed and published, Employee Devices was updated in the Tech Carbon Standard. It is split into “Onsite Employee Devices” and “Offsite Employee Devices” to correctly capture the GHG scopes they each fall within. This particular detail was not captured during this assessment.

Estimated emissions

Estimate used: Detailed = 116.02 kgCO₂e/year - 23% of overall digital estate

Agreed scope

The scope here is the same as the employee hardware category in upstream emissions.

High level estimate methodology

Our starting list of equipment is the same as the employee hardware category in upstream emissions.

Laptops

We weren’t seeking high degrees of accuracy at this point, just something good enough to support an initial, high level estimate. For this we needed an average operational power value for a laptop.

We used an averge operational power use of 0.0171 kWh for laptops, based on data collected from manufacturer PCF data sheets, and previous TCS research. We assume 1760hrs operational hours per year, based on 8hrs per day x 220 days per year.

Therefore we can calculate an average TEC for laptops as:

To calculate the estimated emissions of each laptop we multiply the TEC/year with the regional grid carbon intensity. Finally we apply the the same BYOD attribution of 70% to GWF as we did for upstream emissions.

Germany - 3 laptops (2 BYOD, 1 GWF owned), regional grid carbon intensity 0.364kgCO₂e/kWh:

Parentheses added for clarity.

UK - 1 laptop (BYOD), regional grid carbon intensity 0.268kgCO₂e/kWh:

Netherlands - 1 laptop (BYOD), regional grid carbon intensity 0.386kgCO₂e/kWh:

Taiwan - 1 laptop (BYOD), regional grid carbon intensity 0.566kgCO₂e/kWh:

Total carbon emissions of employee laptops: 52.01kgCO₂e/year

Monitors

For monitors we used an average TEC of 45kWh/year obtained from Dell and HP PCF data sheets. As per the laptop calculations above we multiply this by the regional grid carbon intensity and apply the 70% BYOD where applicable.

Germany - 3 monitors (2 BYOD, 1 GWF owned), 0.364kgCO₂e/kWh:

Parentheses added for clarity.

UK - 3 monitors (BYOD), 0.268kgCO₂e/kWh:

Parentheses added for clarity.

Netherlands - 1 monitor (BYOD), 0.386kgCO₂e/kWh:

Taiwan - 1 monitor (BYOD), 0.566kgCO₂e/kWh:

Total carbon emissions of employee monitors: 94.63kgCO₂e/year

Printers

For the operational carbon emissions we use an average TEC of 0.17kWh. This is based on datasheets of similar sized and specification printers from Canon (PIXMA G5570, for example). HP and the datasheet for the actual printer owned by GWF do not specify a TEC, so we use the Canon printer as a proxy. We simply apply Germany’s carbon intensity of 0.364kgCO2e/kWh to estimate the printer’s operational emissions:

Resulting high level estimate

How could we improve upon this?

As a small team, we felt it to be quite feasible for us to collect information on specific device makes/models to improve these estimates. We went ahead and did this to produce a details estimate.

Detailed estimate methodology

For a more accurate carbon emissions estimate, we gathered specific details of the hardware such as manufacturer and model of the equipment. Our detailed list of equipment is the same as the employee hardware category in upstream emissions.

For each device we looked for a corresponding manufacturer data sheet. However, in some cases even when we did find a data sheet it wasn’t always 100% clear if the specific model’s specification differed from the data sheet. So we used the closest product specification and year of manufacture we could find.

Apple and Dell were particularly easy to find datasheets for. Lenovo and Samsung proved to be more difficult.

For each product, using the data sheets we found the carbon emissions of the use percentage.

Laptops

Apple don’t provide TEC values for it’s products. For this part of our sums we do need this. Instead, they indicate what percentage of the total carbon emissions for any given product is for usage. Using that we can work out a TEC value to use.

Apple’s datasheets indicate that the usage is calculated based on historical customer use, modelling of battery drain for various activities and taking into account regional differences of energy grid mix. So we have to assume that any carbon intensity figure they’ve applied is the global carbon intensity value. We use a global intensity of 0.49kgCO₂e/kWh - see our assumptions page for more info.

Our methodology is to take the product’s use proportion of its total carbon emission and divide that by the expected life in years. This gets us the usage carbon emissions per year (kgCO₂e)/year. We divide this again by the global intensity to calculate a TEC (in kWh/year) for each product.

Then, we factor in where each laptop is actually used in practice to get an annual operational emissions estimate. We do this multiplying the TEC by the relevant regional grid intensity figure. Lastly, we take the actual days attributable to GWF into account, assuming a seven day week.

Monitors

Manufacturers typically provide the TEC for monitors. Using that for each monitor, we then apply the regional carbon intensity and working days for GWF much like we did for laptops.

* Approximately equivalent product that could be found with a PCF data sheet.

Printers

Because we didn’t find any further details about the small office printer, we decided to stick with the high level estimated value of 0.06kgCO₂e/year

Resulting detailed estimate

Employee Device Total 116.02 kgCO₂e/year

How could we improve upon this?

Our high level estimate used an average TEC of 30.1 kWh/year metric for laptops, and the detailed, calculated average TEC estimation came in at 26.9 kWh/year. Taking into account regional carbon intensity, the carbon emissions high level estimate for laptops is 52 kgCO₂e/year and the detailed estimate of 31.4 kgCO₂e/year. Our estimated laptop TEC was higher than the actual laptop TEC and also taking into account the actual working days per week we could be more confident with the estimation. Further comparison of high level and detailed estimates in other projects would be helpful to strengthen the confidence of using the high level average figures.

For the monitors we assumed an average TEC of 45kWh/year, but the actual average was much higher at 60kWh/year due to GWF more larger screens than the average business office (22-24”). This consequently meant the high level estimate of 128.16 kgCO₂e/year was much lower than the actual 181.3 kgCO₂e/year (assuming full time use). Once we accounted for actual working use and not full time hours, this conveniently re-aligned closer to the original estimate at 118.38 kgCO₂e/year.

To the top

Networking and Infrastructure

Estimated emissions

Estimate used: High level = 40.33 kgCO₂e/year - 8% of overall digital estate

Estimate confidence: medium

Agreed scope

The scope here is the same as the Networking and Infrastructure Hardware category in upstream emissions.

High level estimate methodology

For this estimate, you first need to work out an average power consumption figure.

For the router in the Berlin office, we found its data sheet which uses 10W (0.01kWh)) as the average power consumption.

For the router in the UK office, we couldn’t find a data sheet. Instead we saw the plug for the router had a maximum power load rating of 18W written on it. We assumed an average use of 60%. This is based on data found in the two research papers listed below. This resulted in a similar figure of total power of 10.8W (0.0108kWh).

Paper 1 - Equipment power consumption in optical multilayer networks – source data. - Idzikowski, Filip & Heddeghem, Ward & Idzikowski, F & Vereecken, W & Colle, Didier & Pickavet, Mario & Demeester, Piet. (2012).

Paper 2 - Electricity Intensity of Internet Data Transmission: Untangling the Estimates. Journal of Industrial Ecology, 22: 785-798. - Aslan, J., Mayers, K., Koomey, J.G. and France, C. (2018).

We also assumed the routers are operating 24 hours a day, all year round. Lastly we factored in the regional grid carbon intensity of each router’s location to estimate the emissions.

Germany (0.364kgCO₂e/kWh)

UK (0.268kgCO₂e/kWh)

The UK office being a co-shared office space with two other organisations sharing the router, the attribution to GWF is only one third of this value:

This results in an estimate of 40.33kgCO₂e/year.

How could we improve upon this?

For our very simple network set up, we could increase our confidence in this methodology from medium to high by using an energy monitor on the plug to the router to gain an accurate measurement. But for a use case like this we expect the embodied carbon in the monitor would far outweigh the value gain from such a measurement - probably best to borrow one!

For a more complex network setup, where there could be viable mitigation actions, that approach may be justifiable. Depending on the network size you could monitor representative devices and extrapolate their energy usage from there. For example, if you had 5 switches, 3 wireless access points, a firewall and a router, you could capture data on one of each device type and assume the values of remaining switches and access points share a similar profile to the one you measured. If you had reason to believe there would be differences then more measurement would be required.

This approach would only scale so far though and is high effort. Further research needs to be done in this area to create a more robust model that could be used based on devices, their power profiles, and traffic patterns. We predict that features such as power saving and the pattern of traffic is far more important than traffic quantity. We hypothesise that, given a network device with power saving features, frequent, small amounts of data are more power intensive than short bursts of large data.

To the top

Servers and Storage

Estimated emissions

Estimate used: High level = 0 kgCO₂e/year - 0% of overall digital estate

Estimate confidence: n/a

Agreed scope

GWF does not own any of it’s own servers or storage hardware. This means there are no carbon emissions to report in this category and we’re highly confident about this.

To the top

Generators

Estimated emissions

Estimate used: High level = 0 kgCO₂e/year - 0% of overall digital estate

Estimate confidence: n/a

Agreed scope

GWF do not operate any generators on premise. This means there are no carbon emissions to report in this category and we’re highly confident about this.

To the top

Cloud Services

Estimated emissions

Estimate used: High level = 26.74 kgCO₂e/year - 5% of overall digital estate

* A subset of services contained within All Cloud Services.
** The embodied carbon emissions uses the high level estimation model.

NB: We started by producing a high level spend-based estimate of GWF’s cloud services. This led to producing a detailed carbon estimate specifically for GWF’s Greencheck API servers, which is a subset of the whole cloud services estate. So we can’t compare the total high level estimate to a total detailed estimate, as we didn’t complete a detailed estimate for all the servers. However, we do have a comparable result for the Greencheck API as we completed both a high level and detailed estimate for that part.

Agreed scope

GWF use two cloud suppliers to host their Green Web Dataset and accompanying tools, these are Hetzner and Scaleway.

The scope of this section was therefore estimating GWF’s usage of these two suppliers, particularly the VMs, storage and server back-end services.

High level Estimate Methodology

We used a spend-based method to estimate the high level carbon emissions. Unfortunately, we could not find specific methods for Hetzner or Scaleway. Instead, we used AWS as a proxy so that we could use the open-source spend-based model from Cloud Carbon Footprint (CCF). We felt this was good enough to produce a high level estimate in order to quantify the scale of emissions.

Hetzner VMs

For the VMs, we mapped the GWF server instances to equivalent appliances in AWS. Where there was no direct match, we mapped to the next service up that would still meet the services needs. We ended up with just two instance sizes.

As an aside, during this mapping exercise we observed that Hetzner offers far more granular server specifications than AWS. AWS seems designed to push you up the appliance sizes faster. If you want more memory, you have to also take more virtual CPUs, regardless of if they are needed or not.

For the embodied carbon estimate, we pulled spend-based data from CCF. For the two identified instance sizes we obtained values of 0.018364507 kgCO₂e/USD and 0.015829902 kgCO₂e/USD. For ease in the calculations below we round these embodied carbon estimates to 0.018kg CO₂e/USD and 0.016 kgCO₂e/USD.

We got the monthly billing data provided by Hetzner and converted it from Euros to US Dollars at the exchange rate of April 2024. Month to month, this spend does not vary much, so for a high level estimate we assume this same spend every month for the year.

We multiplied monthly spend by the embodied kgCO₂e/USD for each instance type, and multiply that by 12 to get an annual figure:

The combined embodied emissions value is therefore:

For usage emissions, we sourced a kWh per USD value from CCF. We arrived at 0.270373921 kWh/USD and 0.233471074 kWh/USD. For ease in the calculations below we round these usage carbon estimates to 0.270 kWh/USD and 0.233 kWh/USD.

We multiplied the kWh/USD by the monthly cost in USD to obtain a compute kWh/month, then we multiplied that by 12 months to get a total compute kWh/year:

To convert that to a carbon emissions estimate, we needed a carbon intensity value for the electricity used to power the VMs. In this case, the Hetzner data centre used by GWF uses 100% renewable energy, specifically a 50/50 mix of hydro and wind power. To account for this we use the median carbon intensities of hydro and wind power; 0.024 kgCO₂e/kWh and 0.0115 kgCO₂e/kWh (average of onshore wind of 0.011 kgCO2e/kWH and offshore wind of 0.012 kgCO₂e/kWh) as per the Intergovernmental Panel on Climate Change (IPCC) report. We can calculate the average carbon intensity as:

Then we calculate the carbon emissions of the Hetzner VMs:

Then, we add the embodied and operational carbon emissions together for each VM instance:

This results in an estimate of 25.06 kgCO₂e/year for the Hetzner VMs.

Hetzner Data Storage

For the data storage in Hetzner we assume the use of SSD storage and use a value of 0.0012 kWh/TBh from CCF’s Storage Methodology. With a total volume of 0.89TB of data storage we can calculate a yearly kWh:

We then multiply this by the carbon intensity value. As before we’re using 0.0195 kgCO₂e/kWh.

Our estimate for the Hetzner data storage is 0.18 kgCO_2e/year.

Scaleway Data Storage

GWF use Scaleway for object storage. So, we used the same methodology as for the Hetzner data storage. One key difference was that Hetzner allocates a fixed amount of storage while Scaleway charges per gigabyte hour.

Typically GWF uses 463.579 TBhours of data per month. We again assumed SSD storage and use a value of 0.0012 kWh/TBh from CCF’s Storage Methodology.

Scaleway also uses sustainable energy sources, 100% wind or hydro. So, we’ll use the same carbon instensity as above with a 50/50 mix of hydro and wind power; 0.0195 kgCO₂e/kWh:

Our estimate for the Scaleway data storage is 0.13 kgCO_2e/year.

Resulting High level Estimate

How could we improve upon this?

For this particular project, given that the VMs are 99% of the emissions it makes sense to focus on trying to improve this part. Specifically, swapping billing information for actual CPU usage data. The problem with billing information when used as a usage indicator is that it is subjective. For example, one company may negotiate a betting pricing structure than another due to their size. A better approach is using specific CPU data. For example, there is usage data available from the Hetzner API and that could be combined with data about the actual CPU being used, not an AWS equivalent/proxy.

Detailed Estimate Methodology

Hetzner VMs

To improve upon our high level methodology we took a look at blog from Etsy on Cloud Jewels, which the CCF methodology is based on. Reviewing the detailed methodology in their GitHub repository, we arrived at a more detailed method of estimating the operational carbon of cloud VMs.

The following detailed methodology was focused specifically on four of GWF’s servers that provide the greencheck API, as they are known to be the most popular service and using the most resources. We used values obtained from the Hetzner reports for April 2024 as a representative average month to keep things simple, but more accurate numbers could be produced by using data obtained for the whole year.

1. Calculate the Coefficient

The coefficient gives us the number of Watts a single virtual CPU uses based on the type of physical CPU in the server and the workload of the CPU over time. To calculate this:

1. Find out the specific processor being used. The Hetzner API reported that the appliance running the Greencheck API uses an AMD Epyc Processor running at 2.4 GHz.
2. Get the number of threads, maximum and minimum average power draw for processor. We used Spec.org to find specific data for our processor. Ideally, we would find all uses of the chosen processor and average out the values. For speed we used the first matching row.
3. Work out the minimum power per thread. Divide the minimum power draw for the CPU by the number of threads.
4. Do the same for the maximum.
5. Calculate the average utilisation for the month. The usage data supplied by the Hetzner API came in handy here.

Next, we apply the following formula from the Cloud Jewels methodology to get the energy coefficient:

Here are the specific values we used:

2. Work out the monthly electricity consumption of the servers

1. Multiply the coefficient by the number of hours in a year (8760) to gather Wh/CPU per year.
2. Multiply that by the PUE (1.16).
3. Multiply that by the number of servers (4) for total energy consumption per year.

3. Factor in carbon intensity for electricity

Finally we multiply the values by the carbon intensity of hydro and wind power mix, 0.0195 kgCO₂e/kWh.

The resulting detailed operational carbon emissions estimate for the four Hetzner VMs is 0.94 kgCO₂e/year.

We experiment with a different carbon intensity value in the cloud services reducing impact write-up.

To combine the embodied carbon of these servers, we need to rely on the high level methodology (without knowing the specific details of the server’s embodied carbon). In this case we are specifically taking into account the four servers we have looked at in the detailed calculations above, and not the total embodied carbon of all of GWF’s servers we concluded in the high level-estimate.

We use the spend based value of 0.018 kgCO₂e/USD and the cost of $40.33 USD.

Combining this high level embodied carbon estimate, with the detailed operational estimate for the VMs total carbon emissions per year:

Detailed total carbon emissions of the four Hetzner VMs used for Greencheck API = 9.65 kgCO_2e/year

However, to compare this detailed operational estimate to the high level estimate we would need to gather the processor and utilisation data for all of the other servers (which we didn’t have time to do). Alternatively, we can re-calculate the high level operational estimate specifically for these four servers using the spend based method, where the spend is $40.33 USD/month and the kWh/month value of 0.27 kWh/USD:

Then apply the carbon intensity of hydro and wind power mix; 0.0195 kgCO₂e/kWh:

The detailed emissions estimate can now be directly compared to the high level estimate:

* We use the high level estimated embodied carbon, without the specific server’s embodied carbon data.

The high level operational emissions are ~2.7x higher than the detailed operational estimate. High level estimations, especially a spend-based model, are typically higher than detailed estimations (as they tend to over-estimate), and in this case it is signifantly higher. As noted in the high level methodology, we used CCF’s modelling to map the Hetzner servers to AWS servers, meeting all of the minimum service needs, this led to over-sizing the server instances. So, compounding the over-estimated spend-based model, with over-sized server instances, it is a likely reason for such an extreme over-estimation.

Notably, however the embodied carbon makes up 77% - 90% (high level - detailed) of the total carbon. Which means that for the total carbon emissions, the high level estimate is only ~1.2x higher than the detailed estimate. This is however, based on the same high level (likely over-estimated) embodied carbon estimate lacking any specific server embodied carbon data.

How could we improve upon this?

With more time and resources, the detailed estimate could be much improved. Firstly, as we only commited to detailing the four servers used for the Greencheck API, this modelling could be extended to all of the servers. This would require gathering more data regarding the processors used, the processor’s min/max power, number of threads and the average CPU utilisation for each server. Also, we only used the month of April as a sample of average CPU utilisation. This modelling could be applied to every month of the year, for a monthly comparison, or simply calculate the average utilisation for the entire year.

We didn’t gather any detail of the server’s embodied carbon. This would likely need to be obtained from Hetzner if they would be willing to share more details of the hardware. As a high proportion of the total carbon emissions, this could have a significant impact on the total emissions.

One last point around the compatibility of this approach with the GHG Protocol. If cloud services fell into our scope 2 (eg in our direct control such as on-premise), it’d be better to use the regional intensity figure for the data centre’s location, and separately list the market-based figure of zero. This is what the GHG protocol suggests. But we did something different and used the IPCC figures for wind and hydro instead. However, the GHG Protocol guidance is a bit ambiguous on scope 3, which is where our data centres actually fall in this context.

You could argue that our scope 3 should be kept inline with what you do at the scope 2 level. In that case we’d swap the carbon intensity figure used for the regional ones. As an example, the Hetzner machines would use the regional intensity figure for Finland, their actual location. In our own CO2.js data that’s 0.07916. Compared to the IPCC hydro/wind figure of 0.0195, that’s around four times bigger. This would increase our figures a fair amount.

But, you can pick holes in using the regional carbon intensity approach for scope 3, so it’s not clear cut. Either way you’d need to be super clear on the approach. Which route we’d settle on would require a bit more thought, as we only picked up on this point right at the closing stages of the project.

To the top

SaaS Services

Estimated emissions

No data

Estimate confidence: n/a - not attempted

Agreed scope

We started by identifying the SaaS products most prominently by the GWF team. We used GWF’s internal finance tracker to generate a starting list. We realised early on that trying to measure everything was inpractical so looked for the top 10. The first version of this list we settled on is:

• GitHub
• NPM
• Google workspaces, specifically GDrive and Calendars
• Trello
• Zulip
• Miro
• Brevo
• Sentry
• 1password
• 34SP, specifically WordPress hosting

High level estimate methodology

The idea for this was to see what data exists to help us make some high level estimates against our own use of these services. After drawing on our own knowledge of these products and supported by an internet search for useful information, we concluded that data to support these kinds of estimates is not yet readily available. Due to time constraints, we decided to prioritise our efforts elsewhere.

How could we improve upon this?

In an ideal world we would reach out to the relevant SaaS support teams to raise this issue with them. In the absence of data, one of the most useful steps a team can take is to tell a supplier they are looking for it.

We also could have looked for any kind of industry benchmarks and extracted some broad assumptions from those. Whilst those would have provided low confidence estimates, that would have been better than nothing.

If we had the capacity to explore this further, we could consider a spend-based method for high level estimates.

To the top

Managed Services

Estimated emissions

Estimate used: High level = 0 kgCO₂e/year - 0% of overall digital estate

Estimate confidence: Medium

Agreed scope

Cloudflare is a Content Delivery Network (CDN) that GWF use to provide better performance for their websites and manage DNS settings. We put Cloudflare into this Managed Services category, but it could just as easily belong to the Cloud Services category instead. We ultimately took the decision as this category would have been empty otherwise, and we liked being able to separate Cloudflare clearly.

High level estimate methodology

Cloudflare report they operate a (market-based) net-zero carbon service via Renewable Energy and Offset Purchases. This meant we can report the carbon emissions for this as zero in our own digital estimates.

How could we improve upon this?

We briefly explored what a high level estimate methodology for Cloudflare would look like if they didn’t have their decarbonisation strategy. We found two key pieces of information:

1. Cloudflare’s total emissions was 21,000MTCO₂e for 2022 - Cloudflare’s Emissions Inventory for 2022
2. Cloudflare (as of August 2023) has 7.59million active websites - Cloudflare Stats for 2023

A rudimentary method is to simply divide the carbon emissions by the number of active websites to get an average carbon emission per website per year.

In the absense of any data whatsoever, 2.77 kgCO₂e/year per website could be used an average or proxy metric to perform a high level estimate of CDNs.

To the top

Next - Estimating the Downstream Emissions