Methodology
How GreenScope calculates Software Carbon Intensity scores, as required by the SCI Specification.
The SCI Formula
E = Energy consumed by the software, in kWh
I = Location-based marginal carbon intensity of the electricity grid, in gCO2eq/kWh
M = Embodied emissions share (hardware manufacturing footprint), in gCO2e
R = Functional unit — number of HTTP requests handled
The result is expressed in gCO2e per request — the carbon cost of a single HTTP request to the application.
Energy Estimation (E)
CPU seconds are collected from Prometheus via cAdvisor's container_cpu_usage_seconds_total metric.
This is converted to energy using the host CPU's thermal design power (TDP).
Configured values:
- TDP: 205.0W
- CPU cores: 2
- PUE: 1.2 (data center power overhead)
Carbon Intensity (I)
Real-time regional carbon intensity is fetched from the UK Carbon Intensity API, a free public API provided by National Grid ESO.
Rather than using the national average, GreenScope queries the regional endpoint for the specific grid region powering the datacenter. The dreamfold.dev infrastructure runs on DigitalOcean LON1, which is physically hosted at Equinix LD5 in Slough (postcode SL1), falling in the SSE South distribution network region.
- Datacenter postcode:
SL1 - Grid region: SSE South (South England)
- Update frequency: every 30 minutes per half-hour settlement period
- Includes electricity generation mix breakdown (wind, solar, gas, nuclear, etc.)
- Fallback chain: regional → national → static (230.0 gCO2eq/kWh UK average)
Embodied Emissions (M)
TE (Total Embodied Emissions) = 1205.52 kgCO2e — the total manufacturing carbon footprint of the server hardware.
TS (Time Share) = measurement period / server lifespan — the fraction of the hardware's life used in this period.
RS (Resource Share) = app CPU seconds / total available CPU seconds — the fraction of hardware used by this app.
Configured values:
- Total embodied emissions: 1205.52 kgCO2e
- Expected lifespan: 4.0 years
Functional Unit (R)
The functional unit is one HTTP request. Request counts are collected from Prometheus using application-specific metrics:
- FastAPI apps:
http_request_duration_seconds_count(via prometheus-fastapi-instrumentator) - Caddy (meWeb):
caddy_http_requests_total
HTTP requests were chosen as the functional unit because they represent the primary user-facing work performed by these web applications and are already instrumented via Prometheus.
Software Boundaries
Each app's SCI score includes the CPU energy of its constituent containers:
evm-backend,
evm-frontend,
evm-db
equicalendar
planespotter-api,
planespotter-frontend,
planespotter-sync,
planespotter-db,
planespotter-cache
meweb
greenscope
Excluded: Shared infrastructure (Prometheus, Grafana, Loki, Promtail, cAdvisor, GreenScope itself) is not attributed to individual apps. These are observability services that serve the platform as a whole.
Limitations & Accuracy
- CPU-only energy estimate: Only CPU energy is modelled. Memory, storage, and network energy are not included. For these workloads, CPU is the dominant energy consumer.
- TDP-based estimation: Energy is estimated using TDP as a proxy for per-core power. Actual power draw varies with utilisation, temperature, and frequency. This is an overestimate at low utilisation.
- Shared hardware: The host runs multiple apps. Embodied emissions are allocated proportionally by CPU time, which may not perfectly reflect actual hardware wear.
- Network excluded: Energy consumed by network infrastructure (switches, routers, CDN) between the server and end user is not included.
- Client-side excluded: Energy consumed by the user's device to render the page is not included.
- Measurement interval: Calculations run every 15 minutes. Short-lived spikes within a period are averaged out.
Contact
GreenScope is built by Darryl Cauldwell. For questions about this methodology, please visit dreamfold.dev.