GLPI Carbon plugin: measuring IT carbon footprint

How the GLPI Carbon plugin measures IT carbon footprint

The GLPI Carbon plugin estimates energy use and emissions for computers, monitors and network devices from the inventory records already in GLPI, combined with usage assumptions and carbon intensity inputs. The result is only as good as those inputs, so the estimate is a model, not a metered measurement. Teams usually implement it when a sustainability or finance function asks for IT energy or emissions figures and the asset register is already the most complete list of hardware the organization owns. That is a sound starting point, but the register must be accurate about device models, locations and status before any calculation means anything.

Before scoping, confirm the plugin's exact inputs, the device types it covers and whether it supports GLPI 11 and 12 from the plugin's own listing and documentation, since these details change between plugin releases and are not covered by the GLPI core release notes. Ask the plugin maintainer which fields it reads, how it handles devices without power data, and where the carbon intensity values come from. Also confirm the license and whether the source is published, because an estimate you cannot trace back to its assumptions will not hold up when an auditor or customer asks how a figure was produced.

Plan the work around the inputs rather than the plugin screens. Decide which usage profile applies to each device class, who owns the assumptions, and how often the carbon intensity figures are refreshed and recorded with each report. Test the calculation on a small, known set of assets and compare the output with a manual calculation before rolling it out to the full inventory. Keep the GLPI database and configuration backups current before installing or upgrading the plugin, since a plugin change that alters asset data is hard to reverse after the next report has been issued.

What the Carbon plugin estimates from GLPI data

The estimate is only as good as the records behind it. GLPI holds the hardware and software inventory, GLPI Agent supplies much of that data, and the Carbon plugin builds its calculations on those records. Each card below is a component you need to confirm before you trust the totals.

Device records from inventory

The starting point is the computer, monitor and network device records already in GLPI. These come from the hardware and software inventory that GLPI Agent sends, or from records entered by hand. Check which device types the plugin version you run treats as energy consumers, and whether monitors and network equipment are counted as separate assets or only as attributes of a computer. Records missing a model, or with a placeholder model name, will fall back to generic assumptions, so audit those before running a report.

Usage profiles

Power draw depends on how long a device is on and under what load, not only on its model. The plugin's usage profiles set those assumptions, such as hours per day, days per year and an idle or active share. The plugin's own defaults may not match your fleet, so ask for the default values, where they are stored, and whether profiles can be set per asset type, location or entity. Document the profiles you adopt, because the report is only as defensible as the assumptions behind it.

Carbon intensity sources

Emissions depend on the carbon intensity of the electricity used, which varies by country, region and sometimes by supplier contract. Confirm which intensity sources the plugin ships with, whether you can enter a location-specific factor, and how the factor is dated. Using an annual national average for a site with a contracted renewable supply will produce a different result than using a supplier-specific figure, so record which basis each report uses.

Energy and emissions calculation

The plugin combines device records, usage profiles and intensity factors into estimated energy use and emissions. Treat these as estimates, not measured values. Ask the plugin's maintainers how the formula is documented, whether inputs can be inspected per asset, and how results change when a single input is edited. A calculation you cannot trace to its inputs will be difficult to defend in an internal or external review.

Reporting output

Reports summarize estimates by entity, location, asset type or time period. Confirm which breakdowns, export formats and date ranges the plugin supports, and whether reports can be filtered by GLPI entity so that each business unit sees only its own data. Also check whether results are stored as snapshots or recalculated on each view, since a recalculated figure changes when inventory or profiles change.

Data currency and gaps

An estimate can only cover devices GLPI knows about. Stale records, retired assets still marked active, and devices that never reported inventory will skew totals. Before reporting, compare inventory coverage against your asset register, decide how retired equipment is excluded, and set a schedule for re-running inventory. Ask the plugin's maintainers how it handles assets with no usage profile or intensity factor, since silent defaults can hide gaps.

Choosing usage profiles and carbon intensity sources

This table compares the main configuration choices for carbon estimates in GLPI: how device energy is modeled, where grid intensity comes from, and how often inputs are refreshed. Read each row against your estate's size, hardware uniformity and number of sites, then note the accuracy or effort you accept. The main takeaway is that the cheapest setup is usually adequate for a single-site estate, while multi-site estates need location-based inputs to avoid misleading totals.

Decision	Option	Trade-off	When it fits
Device energy model	Usage profiles by device class	Fast to set up, but every laptop of one model gets the same estimate regardless of how it is actually used	Small estate with uniform hardware and similar working patterns
Device energy model	Per-device measured values	Closest to reality, but needs power readings or manufacturer data for each asset and ongoing upkeep as assets change	Regulated reporting where assessors ask how each figure was derived
Device energy model	Hybrid: profiles by default, measured values for exceptions	Balances effort and accuracy, but reviewers must document which rows use which method	Mixed estates with a few high-draw servers or specialist equipment
Grid intensity	Single average for the whole organization	Simple to explain, but hides differences between regions and overstates or understates some sites	One country or one site with a single electricity supplier
Grid intensity	Location-based intensity per site or entity	Needs each site mapped to a grid source and maintained, but reflects where devices really draw power	Multi-site estates or entities spread across different grids
Input refresh	Static values reviewed yearly	Low effort, but grid mix changes over time and the report can drift from current conditions	Internal trend reporting where comparability across years matters more than precision
Input refresh	Periodic refresh aligned to reporting cycles	Requires a named owner and a dated record of each source version used	Formal reporting periods where each figure must be traceable to a source date
Scope of devices	Computers and monitors only	Covers the largest share of user-side equipment, but omits network and server load	Early programs focused on end-user equipment

Which inventory fields to fix before estimating

An carbon estimate is only as good as the inventory it reads, so clean the device records before you enable any calculation. The plugin turns each computer, monitor and network device into an energy figure using attributes such as device type, model, location, entity and status. If a laptop is recorded as a desktop, or a switch has no model, the estimate falls back to a generic assumption and the total looks precise while being wrong. Confirm with the plugin documentation and your installed version exactly which GLPI fields it reads, which fallback values it applies when a field is empty, and whether it filters on status or entity. Those answers define your cleanup scope.

Three problems distort totals most often. Agent re-imports can create duplicate computer records for the same machine, especially after a rename, a reinstall or a change in hostname, so the same device is counted twice. Retired assets that still carry an active status keep contributing power draw and emissions for hardware that is no longer in service. Devices with no location cannot be matched to the regional carbon intensity you apply, so they fall to a default that may not reflect where they run. Pull a report of duplicates by serial number and UUID, of active assets not seen by the agent in a period you define, and of assets with an empty location, then review each group by hand before you change anything.

Set a written source-of-truth rule before the cleanup starts. For example, you might decide that agent data wins for hardware attributes such as model and serial number, while manual records win for location, owner and lifecycle status, with a named person approving any conflict. Record the rule where the GLPI administrators can find it, and apply it the same way to every entity. Then rerun the cleanup after each agent inventory cycle, since the carbon figures will drift back as soon as new imports arrive unchecked.

Implementing the IT carbon footprint estimate in sequence

This sequence turns GLPI inventory into a carbon estimate that finance and sustainability leads can review and repeat. Each step ends with a named output, so the team can confirm what was checked before the next step begins. Confirm plugin behavior against the publisher's documentation at each stage.

Confirm plugin and GLPI compatibility
Check which GLPI versions the Carbon plugin supports, comparing your current instance against GLPI 11 or GLPI 12. GLPI 12.0.0 was released on October 7, 2026, so confirm in writing whether your plugin release has been tested against it before you plan an upgrade. Ask the plugin publisher to name the supported GLPI and PHP versions for the build you intend to install. Output: a short compatibility note that records the GLPI version, the plugin version and the publisher's confirmation.
Back up database, files and keys
Before installing, take a backup of the database, the GLPI application files and the config directory, including glpi.key and glpicrypt.key, as the GLPI update documentation requires. Keep the key files with the backup set, since encrypted settings depend on them, and test that the set can be restored in a separate environment. Note that GLPI suspends plugins after it detects a new version, and that plugins must be reactivated after major updates, so include that check in the change window. Output: a verified backup set and a dated record of the GLPI and plugin versions in use.
Clean asset data before estimating
Review computer, monitor and network device records in each entity you plan to include. Remove duplicates, mark decommissioned items as retired, and complete the model, location and status fields that the estimate depends on. Use the inventory collected by GLPI Agent where it is available, and confirm with the plugin documentation which fields it reads. Output: an exported asset list per entity and a cleanup log that shows what changed and who approved each change.
Set usage profiles and intensity sources
Define usage profiles for each device class, covering assumptions such as hours in operation and power states, and record the carbon intensity source you use for each region. Ask the plugin publisher which inputs it accepts and which sources it documents, then write down the basis for every value. Agree these choices with sustainability leads before any figures are produced. Output: a versioned assumptions register that lists each profile, each intensity source, its date and its owner.
Run the estimate on a sample entity
Run the estimate against one entity whose asset records you have already checked, so the team can compare output with records it trusts. Confirm that the device counts in the report match the cleaned asset list and that units and totals are consistent. When a figure looks wrong, correct the input data or the profile and run again, rather than editing the output. Output: a sample report and a reconciliation sheet that lists inputs, outputs and any open issues.
Review results with finance and sustainability
Walk finance and sustainability leads through the sample results, the assumptions register and the known gaps in the data. Ask them to challenge the usage profiles and intensity sources, and record each decision along with any open question. Agree how the figures will be labeled in reports, including a statement that they are estimates and the method used. Output: approved assumptions and a decision log. Expanding to further entities should wait until this review is complete.
Schedule recurring runs after approval
After the assumptions are approved, run the estimate across the agreed entities and set up a recurring schedule using the scheduling options available in your GLPI instance, so that inventory changes reach the reports. After each GLPI or plugin upgrade, confirm that the plugin is active again, because it is suspended when a new GLPI version is detected and must be reactivated after major updates. Output: a recurring run schedule, a run log and a review date owned by a named person.

What drives cost and effort for carbon reporting

This table lists the factors that change the effort of a GLPI Carbon estimate, whether each one is paid once or recurs, and how to keep it manageable. Read it as a checklist for scoping, then use the final row to shape the written quote. The main takeaway is that data quality in GLPI inventory usually matters more than the number of devices.

Driver	Why it changes effort	One-time or recurring	What keeps it down
Device records and data quality	Each computer, monitor and network device needs a model, power profile and location to produce a credible estimate. Missing or duplicated records add cleanup work before any calculation.	One-time cleanup, then recurring as new assets arrive	Clean models and manufacturers in GLPI before scoping, and keep inventory agents running so records refresh automatically
Agent inventory coverage	Where GLPI Agent already reports hardware, the team can use collected data. Where it does not, device data must be entered by hand or collected another way.	One-time rollout if agents are missing, recurring maintenance afterward	Confirm which device classes already report and scope manual entry only for the gaps
Sites and electricity grids	Each site may fall under a different grid and carbon intensity source, so each location needs its own factor and an assumption that someone signs off.	One-time setup per site, recurring when grid data is refreshed	Group sites that share a grid, and limit the set of intensity sources to the ones your reporting policy accepts
Usage profiles	Estimates depend on how many hours devices run and at what load. Each distinct profile, such as office desktops, shared meeting room screens or network closets, adds definition and review work.	One-time definition, recurring review when working patterns change	Start with a small set of profiles and validate them against sample observations before adding more
Number of reporting audiences	Finance, sustainability, facilities and executive readers often need different groupings, periods or levels of detail. Each audience adds report design and review.	One-time report design, recurring when audiences request changes	Agree one core dataset and derive audience views from it rather than building a separate report for each group
Assumptions and sign-off	Estimates rest on stated assumptions. Each assumption that needs approval from your own team adds review cycles before the numbers can be used externally.	One-time for the initial set, recurring at each reporting period	Write assumptions down with their source and owner before the build starts
What to request in a written quote	A fixed scope is easier to compare. Ask for the list of required inputs, the assumptions to be signed off, the device classes and sites in scope, and the handover format for the dataset and the documentation.	Applies once, at scoping	Ask the partner to name each input you must supply and each assumption that stays with your team after handover

How the approach differs by estate: endpoints, monitors and network devices

Computers are usually the best-documented part of a GLPI estate. When GLPI Agent runs on workstations and servers, it sends hardware and software inventory to GLPI, including the manufacturer, model and hardware components that a carbon estimate depends on. That makes agent-collected inventory the usual starting point for computer records. The agent is the successor of FusionInventory Agent and runs on Windows, macOS and Linux, so most endpoint fleets can feed the same data.

Model and hardware data: Agent inventory records the model and components, which drive the power assumptions used for each machine.
Coverage gaps: Machines that never run the agent, such as disconnected laptops or retired devices still listed as active, leave holes in the total.
Stale records: A machine replaced under the same asset tag keeps the old model until the inventory updates, so check the last inventory date.
Usage profiles: Inventory describes what a machine is, not how long it runs, so usage hours usually need an assumption or a separate source.
Ownership and location: Linking each computer to an entity or location lets you report by site and business unit.

Before reporting, confirm with the plugin documentation which inventory fields it reads for computers and how it handles devices with no model match.

How carbon data connects to inventory, agents and reporting

A carbon estimate is only as good as the device records behind it. The cards below follow the path from agent-collected inventory through the GLPI database, the permissions that govern who sees results, and the exports and plugin updates that carry figures into other teams' work.

GLPI Agent as the device source

The computer, monitor and network records the plugin uses usually arrive through GLPI Agent, which collects hardware and software inventory and sends it to GLPI. Confirm which fields the carbon calculation reads, such as model, status and assigned location, and whether your agents report them on every run. Devices that never check in will keep stale power assumptions. Ask the plugin publisher which inventory fields are required and how it handles devices with no recent inventory.

Discovery for unmanaged network devices

Switches, routers, printers and access points often have no agent, so their records depend on network discovery. The GLPI Inventory plugin covers discovery and the import rules that create or update those assets. Check whether discovered network devices carry the model and power data the estimate needs, or whether those values must be entered by hand. Confirm with the plugin publisher and your own network team how discovered devices are matched to existing records to avoid double counting.

The GLPI database and its backups

Carbon figures are calculated from and stored alongside GLPI data, so the database backup is also the record of past estimates. Before a plugin install or upgrade, follow the GLPI update procedure, which requires backing up the database, the files and the config directory including the encryption keys. Ask the plugin publisher whether its usage profiles and computed values live in the database, and whether a restore reproduces earlier reports exactly.

Permissions that limit per-site figures

Per-site and per-entity emissions can reveal facility sizes, branch activity and staffing patterns, so visibility should follow GLPI's own profiles and entities. Map which technician, manager and auditor roles can open carbon views, and test that a user in one entity cannot see another entity's totals through reports or dashboards. Confirm with the plugin publisher whether its rights are granted per profile or per entity, and whether exports respect the same restrictions.

Exports to sustainability and finance

Figures leave GLPI when sustainability or finance teams need them in spreadsheets or reporting tools. Each export is a copy that no longer follows GLPI permissions, so agree on who may export, which fields are included and how files are labeled with method and date. Ask the plugin publisher what export formats exist and whether the calculation method is documented in the output so that a reviewer can trace each number.

Plugin updates that change results

A new plugin version or GLPI release can change usage profiles, default wattage or rounding, which shifts reported totals without any change in your hardware. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so schedule that step and record the plugin version alongside each report. Ask the publisher for release notes that state changes to calculation logic, and rerun a fixed sample of devices after every update to confirm the output still matches your baseline.

Carbon footprint plugin questions buyers ask

What does it cost to implement GLPI Carbon footprint reporting?

Implementation cost depends on how much of the work your team already has in place, and no price is given here because no researched figure supports one. The main cost components are the plugin setup and configuration, the mapping of your inventory to usage profiles, the carbon intensity source you choose, and the review of the resulting figures by finance and sustainability staff. Plugin setup is usually a one-time cost, while refreshing usage profiles, updating carbon intensity inputs and rerunning reports recur each reporting cycle. Costs rise with the number of device classes, the number of sites with different grid mixes, and the amount of manual data you must correct. Ask any partner for a quote built from a written scope that separates one-time setup from recurring reporting work.

How long does a carbon footprint setup take in GLPI?

Duration depends on the state of your inventory, not on the plugin alone. A clean, current GLPI inventory of computers, monitors and network devices shortens the work, while missing asset records, duplicate entries and unassigned locations lengthen it. Other drivers are the number of usage profiles you define, the number of sites and grid regions, and how many review rounds finance and the sustainability lead require before accepting a baseline. Confirm the expected schedule in writing with any partner, and ask which steps depend on inventory clean-up you must complete first.

What does the work need from our own staff?

The work needs three groups of people. Inventory owners confirm which devices exist, where they sit, who uses them and which records are wrong, because the estimates are only as good as the asset data. A sustainability lead defines the reporting boundary, the usage assumptions and the reporting period. A finance reviewer checks the cost and cost-allocation logic if the figures feed budgets or internal charge-backs. Each group should name one accountable person and agree on review dates before the build starts, so that open questions do not stall the configuration.

Can our internal team set up the GLPI Carbon plugin alone?

A capable GLPI administrator can install and configure the plugin in-house if the team has time, GLPI experience and a clear method for choosing usage profiles and carbon intensity sources. The harder part is methodological: deciding boundaries, documenting assumptions and explaining the results to auditors, customers or regulators. Teams that lack a sustainability reporting owner often underestimate this work. Consider a partner when the team must also maintain the GLPI deployment, when the plugin must be validated in a separate test instance, or when the output must be explained to external reviewers.

Which figures should we request in a carbon plugin quote?

Ask for a written scope that lists the device classes covered, the number of assets and sites in scope, the GLPI version and hosting model, and the plugin version to be installed. Request a breakdown of one-time work (installation, configuration, usage profile design, validation and documentation) and recurring work (refreshing inputs, rerunning reports and supporting reviews). Ask which carbon intensity sources are assumed, who supplies the data, and whether any subscription or data licence is excluded from the quote. Also ask for the acceptance criteria, the handover documents and the support terms after go-live.

Can the output be treated as an audited emissions value?

No. A plugin-generated estimate is an internal calculation based on your inventory, usage assumptions and chosen carbon intensity sources, and it is not an audit report, attestation or certification. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue any assurance. If an external party must rely on the figures, agree the methodology, data sources and boundaries with that party before reporting, and keep the calculation inputs, versions and change history so the estimate can be reviewed. Confirm the reporting framework your organization must follow with the people who will review it.

What are the main risks of relying on estimated device energy figures?

The main risks are inaccurate inventory, wrong usage assumptions and outdated carbon intensity inputs. A device recorded with the wrong model or location produces a wrong estimate, and assumed hours of use may not match how staff actually work. Grid carbon intensity varies by region and year, so a stale input can misstate results. Reduce these risks by validating a sample of devices against measured or vendor-supplied power data, documenting every assumption, and rerunning the estimate after major inventory changes. Ask your partner how they would test the calculation before you rely on it.

What the estimate can and cannot support in a sustainability report

The GLPI Carbon plugin produces modeled estimates, not metered energy readings. Every figure it shows is derived from inventory records in GLPI, usage profiles that assign hours and load levels to device types, and carbon intensity factors that convert energy into emissions. None of those inputs is a meter reading from the device or the building. Before any number leaves your team, write down that distinction in the report methodology so a reader cannot mistake a model output for a measurement. Confirm with the plugin documentation and your own test run exactly which fields and profiles feed each output, because the reported values are only as current as the inventory behind them.

Document each input as either measured or assumed. Asset records such as model, serial number and location are usually taken from inventory or agent collection, so they can be described as observed, though the power draw attached to a model is typically a reference value rather than a reading from that unit. Usage hours, utilization profiles and grid carbon intensity are assumptions unless you source them from a named dataset or metered supply. Keep a register that lists each assumption, its source, the date it was set, the person who approved it and the components it affects. State the limits plainly: the estimate excludes any device not present in GLPI, depends on the accuracy of the profile chosen for each device class, and does not capture embodied emissions unless your method includes them.

DeployOpen prepares the data, configuration and evidence trail that support the estimate, including the profile settings, the inventory baseline, the assumption register and the exported calculation records. Whether the figures meet a specific reporting requirement is a decision for the independent auditor or the reporting framework's own assurance process, not for the implementation partner or the plugin. Ask your assurance provider early which methodology, boundary and evidence they will accept, and agree on those terms before the first report cycle. Any statement that the figures are verified or certified should be checked against that assurance outcome, not against the plugin's output.

How DeployOpen scopes and delivers the GLPI Carbon plugin

DeployOpen approaches carbon measurement as a deployment and data workstream inside your GLPI instance, not as a sustainability report. We agree what the estimates cover, how inventory data feeds them, and where the assumptions come from, then build and document the setup in infrastructure you control.

How we scope

The written scope lists which computers, monitors and network devices are in the estimate, and which inventory sources feed them.
We agree in writing which usage profiles and carbon intensity sources the estimates use, and who owns updating them.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts. Ongoing support is available as a retainer.

How we build

We check GLPI inventory completeness for device types and models before relying on them as the estimate's input data.
We configure the plugin's usage profiles and emission factors against the assumptions recorded in the scope, with each setting traceable.
We test reports against a sample of known devices and document where results differ from expectations and why.

How we hand over

You receive configuration documentation covering inputs, assumptions, update steps and the reports the plugin produces.
We document how the estimates are reproduced, so an auditor or internal reviewer can follow each figure back to its source data.
Your team receives a walkthrough of routine updates, including reviewing carbon intensity sources when they change.

How we support

Ongoing support covers plugin upgrades that follow GLPI version changes, with plugin reactivation and testing after each major update.
Retainers can include periodic review of usage profiles and carbon intensity sources against your current assumptions.
Confirm with us during scoping which parts of support, testing and updates your retainer covers before work starts.

Measuring IT carbon footprint with the GLPI Carbon plugin