Power Management

Athena sets Windows power settings centrally across your fleet. These include display and sleep timeouts, what the power button and lid do, battery thresholds and actions, processor limits and USB selective suspend. You build named power policies, assign them to agents, collections or tags, and Athena writes each machine's values. Each agent's tab shows whether the machine still matches its policy. All of this runs between your Athena server and its agents, so it works on an air-gapped network.

Where Power Management appears#

• Policies → Power Management (/policies/power), in the Policies group of the left navigation, headed Power configuration. Until October 2026 this was the Settings → Agent → Power Management sub-tab; old /settings/agent/power bookmarks still redirect for one release. It has the Enforce power policies switches, the Power policies list and the Assignments list.
• Agent details → Power, the section after BitLocker. It shows one machine's effective policy, its active power scheme, and each setting's policy value beside the machine's value.

Permissions

Power Management has two permissions. The built-in Admin role has both. View power management is also given to the built-in Helpdesk and Operator roles, because a machine's power settings are not sensitive. Manage power management is also given to Operator. Roles can't be edited in this release, so to give someone a permission, give them a role that holds it. See Roles & Permissions.

Power policies#

A policy is a named set of power settings. Click Add a power policy on the Power Management tab to open New power policy. To change a policy, click Edit in its row.

Managed, "Never" and unmanaged

Each setting in a policy is in one of three states:

• Managed with a value. Athena writes the value and reports drift if the machine has a different one.
• Managed, set to 0. For a timeout, 0 means Never, for example a display that never turns off. This is a real value, and Athena writes and enforces it.
• Not managed (unticked). Nothing is stored and nothing is written. The machine keeps its own value and never reports drift for it. This is not the same as setting it to 0.

You can also manage one side only. Leave either the On battery or the Plugged in value empty and Athena leaves that side of the machine alone. The policy list shows how many settings each policy manages ({n} of 25 settings managed), or No settings managed.

If you open the editor while automatic re-apply is off, it shows a notice: "Policies are not applied automatically. Assigning this policy will show drift but will not change any device until someone presses Apply." See Applying policies.

The 25 settings

Timeouts are entered in minutes in the console, from 0 (Never) up to 24 hours. Percentages range from 0 to 100. Settings marked hidden in the editor do not appear in the Windows Power Options control panel, but Athena sets them anyway.

Assignments#

An assignment links a policy to a target. In the Assignments section, choose a policy (Choose a policy) and a target type, then pick the target (Choose a target) and click Assign this policy to this target. You can target:

• Agent: one machine.
• Collection: every current member of a collection. The collection must exist.
• Tag: every agent carrying an agent tag. The tag does not have to exist yet. Until it does, it matches no agents.

Which policy applies

Each machine gets exactly one policy, which works like a firewall rule list:

1. Assignments are checked in priority order, top first. A lower priority number wins.
2. The first assignment whose target contains the agent decides its policy. Nothing below it is considered.
3. An assignment whose policy is disabled is skipped, and its agents fall through to the next matching assignment.
4. If nothing matches, the agent is unmanaged. Athena writes nothing and the machine keeps its own power configuration.

Settings are never merged across policies. If the winning policy leaves a setting unmanaged, it stays unmanaged, even if a lower-priority policy manages it. This way you can always tell which single policy configured a machine.

A new assignment is added last, with the lowest precedence. Use the Higher precedence and Lower precedence arrows to reorder. Removing an assignment hands its agents to the next matching assignment, or leaves them unmanaged if none matches.

Applying policies#

Editing policies and assignments changes only the plan on the server. Two switches at the top of the Power Management tab decide whether anything reaches a machine. Both are off by default:

You can turn automatic re-apply on while enforcement is off. Nothing is re-applied until both switches are on.

Apply now and Refresh

• Policies → Power Management → Apply now sends each connected agent its policy. The result reads Sent to {n} of {m} connected agents. Agents that are unmanaged, or whose policy manages no settings, are counted but not sent anything.
• The report button next to it asks every connected agent to report its current power configuration (Asked {n} of {m} connected agents to report.). This changes nothing on the machines.
• On an agent's Power section, Apply now sends that one machine its policy. It is greyed out while enforcement is off. Refresh asks the machine to report.

Offline agents are not queued. An apply reaches only agents that are connected when you click. With automatic re-apply on, an agent that was offline gets its policy at its next check-in. Otherwise, apply again once it is online.

Athena writes values into the machine's currently active power plan. It writes only the settings the policy manages, and only the managed side (On battery or Plugged in) of each.

Apply messages

Agent details → Power#

The Power section of an agent shows:

• Effective policy: the policy that applies and why. For example, via Collection Laptops, priority 2, or assigned directly to this agent. An unmanaged agent reads "No power policy is assigned to this agent, so Athena writes nothing here and the machine keeps its own power configuration."
• Active power scheme: the machine's active Windows power plan (Custom scheme if it is not a standard one), and Last reported.
• A table of settings with On battery, Plugged in and State columns. Each value cell shows the value on this machine next to the value from the policy. The table lists every managed setting plus every setting the machine reported.

Agents report their power configuration on their own. It is requested when an agent connects (at most once every 5 minutes per agent), after a policy or assignment change, and on each run of the Power State Collection task. If an agent has never reported, the section says so. Click Refresh to ask it.

Setting states

Machines without a battery (most desktops and virtual machines): the On battery values are neither written nor compared. The section says "This machine has no battery, so the On battery values are neither written nor compared."

Power State Collection task#

A value changed by hand on a quiet machine produces no event. To catch that drift, schedule the Power State Collection task on the Scheduler. It needs power.manage. Each run:

1. re-applies the policy to connected agents that have drifted, but only when both switches are on;
2. then asks every connected agent to report its current power configuration.

With either switch off, the task only collects. Every 60 minutes is recommended. Machines already in sync are sent nothing, so a shorter interval mostly adds reports.

The automatic triggers (check-in and a new report) never resend a policy that a machine has already answered with drift. This stops an endless loop of re-applies. Retries come from this task. If an apply is still in progress (sent less than 10 minutes ago and not yet answered), it is not sent again. Automatic applies are recorded in the audit log with the user name power.autoconverge.

Filter fields#

Power adds four fields for collections, monitors, tagging rules and reports. See Filter Field Reference.

For example, a collection with Module.power.DriftState equals Drift lists every machine whose power settings no longer match its policy.

Audit events#

REST API#

All routes are under /api/power and need a bearer token (see API Reference). Reads need power.view, and everything else needs power.manage. Responses use the standard success / data / message envelope.

In a policy body, values maps a setting key from the catalog to {"ac": …, "dc": …}. Here ac is Plugged in, dc is On battery, and null leaves that side unmanaged. Unlike the console, the API uses the units Windows stores. Timeouts are in seconds (0 to 86400, with 0 = Never). Choice settings take the Windows value, not the option's position in the list: 0 Do nothing, 2 Sleep, 3 Hibernate, 6 Shut down, 8 Turn off the display. For System cooling policy, 0 is Active and 1 is Passive. Off/On, No/Yes and Disabled/Enabled settings take 0 and 1. Wake timers take 0 Disable, 1 Enable and 2 Important only. Out-of-range values are rejected with 400, never adjusted.

The per-agent status and apply routes always return 200. The success flag and message tell you whether the request was sent, using the apply messages above.

For example, a policy that turns the display off after 10 minutes on battery and 30 minutes plugged in, and never sleeps when plugged in:

curl -k -X POST -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{"name":"Office desktops","enabled":true,
       "values":{"display-timeout":{"ac":1800,"dc":600},
                 "sleep-timeout":{"ac":0,"dc":null}}}' \
  "https://<server>:8443/api/power/policies"

Troubleshooting#

Related#

• Collections and Agent Tags: the groups you assign policies to.
• Filter Field Reference: all filter fields, including module fields.
• Scheduled Jobs: scheduling the Power State Collection task.
• Licensing: separately licensed modules.
• Audit Event Types Reference: all audit events.
• BitLocker Management: the other Windows policy module that uses the same policy-and-assignment model.