Teams Keep Awake: Why Power Tools Fail
Learn why Teams marks you Away despite keep-awake apps, how OS input-idle timers work, and the trade-offs of safer macOS and Windows approaches at work.
Why Keep-Awake Apps Don't Keep You Green on Teams
You step away to make coffee, answer the door, or grab a printout. A few minutes later, Microsoft Teams flips you to Away - even though you're back at your desk. A keep-awake utility sounds like the fix, but tools like PowerToys Awake, caffeinate, and Amphetamine often leave your Teams status unchanged.
Here's the catch: computers track two different kinds of inactivity. One affects whether your display dims or your computer sleeps. The other tracks how much time has passed since your last keyboard, mouse, or trackpad input. Keeping the machine awake doesn't necessarily reset the input timer Teams may be using to judge your availability.
Once you see that split, the "workarounds" make more sense - and you can pick the one that matches the problem you actually have. This article breaks down the two timers, compares what you can do on macOS and Windows, and explains when an input-reset tool helps (and when it's just a bad idea). The goal isn't to hide a long absence. It's to understand what's going on so you can make a decision that fits your workplace rules.
Why do keep-awake apps fail in Teams?
"Keep awake" sounds like one simple behavior, but it's really two different OS actions. The first is power-management idle: the time the system uses to decide when to dim the display, start a screen saver, or sleep. The second is input idle time: a counter that increases while the system receives no keyboard, mouse, or trackpad events.
A utility that prevents sleep usually handles the first one. It asks the operating system to maintain a power assertion or delay sleep. That's useful for things like a presentation, a long download, or a process that must finish unattended. But it doesn't automatically simulate user input or reset the input-idle counter.
On macOS, developers can use APIs such as IOPMAssertionCreateWithName to keep the system or display awake. IOPMAssertionDeclareUserActivity can also indicate that user activity occurred for power-management purposes. On Windows, SetThreadExecutionState can request that the system or display remain active. These are all about power management - not about pretending you typed or moved a mouse.
To measure input, macOS exposes counters like CGEventSourceSecondsSinceLastEventType, while Windows provides GetLastInputInfo. These counters answer a different question: when did the system last see input? So a tool can keep the monitor lit while the input-idle value keeps climbing.
Why Teams changes your status
Teams uses inactivity signals to decide presence. In the tests described here, the status switched to Away after about five minutes without input. That timing can vary with Teams behavior, configuration, and organizational policy, so it's best treated as an observed threshold - not a universal rule.
The key point is the mechanism: a power assertion can keep the computer awake without making the input counter look recent. If Teams is reacting to input inactivity, leaving the screen on won't be enough.
What testing shows
You don't have to guess based on a tool's name. In a Windows 11 test machine, calling SetThreadExecutionState didn't stop the input-idle counter from increasing. On macOS, IOPMAssertionDeclareUserActivity postponed display sleep, but left the input-inactivity counter unchanged.
So a keep-awake app can work exactly as intended - and still fail to keep Teams "green." It isn't necessarily broken. It's solving a different problem.
Which workarounds reset input idle time?
Once you focus on the input counter, comparing options gets easier. Some prevent sleep only. Others create an input event, but those events can interfere with normal use.
| Approach | Keeps the computer awake? | Resets input idle? | Main trade-off |
|---|---|---|---|
| Power assertion | Often | No | Does not address input inactivity |
| Mouse jiggler | Not necessarily | Yes | Moves the pointer and can trigger hover behavior |
| Real key press | Not necessarily | Yes | May activate a shortcut or alter the next interaction |
| Neutral or unused-key event | Not necessarily | Yes, in tested cases | Requires careful implementation and testing |
Keep-awake utilities
Caffeinate, Amphetamine, and PowerToys Awake are useful when you need a machine to stay on. They can prevent sleep during a presentation or during a lengthy operation. But they aren't built to keep an input-idle counter low. So installing one just to change Teams presence may not do what you hope.
Mouse jigglers
A hardware or software mouse jiggler generates pointer movement. That usually counts as input, but the movement is visible to the system and can have real side effects. It might wake hover menus or tooltips, shift the pointer away from a control, or "compete" with you the moment you come back.
Even a tiny movement is still a real cursor move, and that's not always a neutral trade-off - especially if you depend on precise pointer placement or use software with hover-sensitive controls.
Real key presses
A normal key event can reset inactivity, but it can also change application state. A function key might trigger a command in the foreground app. Pressing a modifier key (like Shift or Control) can affect the next click or shortcut if the press and release aren't handled carefully.
So the engineering challenge isn't just "create input." It's "create an event that resets the OS's idle counter while minimizing the chance that an application treats it like a command." That matters more for utilities than for one-off manual testing.
How can macOS send a neutral input event?
macOS includes an event type called flagsChanged, which fires when the state of modifier keys changes. The event includes the current modifier flags - Shift, Control, Option, Command, Function, Caps Lock, and so on.
The KeepMeOn project's approach is to post a flagsChanged event using the same modifier state that's already active. If no modifier key is currently held, that event doesn't represent a new character or a typical "key press." In the project's tests, it still counted as input and reset the idle counter.
This is a narrow technique, not a promise that every synthetic event will be ignored by every application. It depends on how macOS and the receiving software handle the event. A working implementation needs to avoid sending it while the user is holding a modifier, and it should be tested against the specific apps and macOS versions you actually use.
Permissions and safety checks
Posting events requires macOS Accessibility permission. The app can check whether event-posting access is available and request it if needed. The project notes that, after granting permission, the app may need to be relaunched because macOS checks the permission when the process starts.
A robust implementation should also:
- Check for held modifiers first. Don't inject an event while the user is doing a Command-drag, Shift-selection, or any other modifier-based action.
- Tag its synthetic event. A marker in the event's user-data field helps event monitors distinguish the utility's event from normal input.
- Fail safely when permission is missing. If the app can't post input, it should say so rather than acting like everything is fine.
- Keep power management separate. The project also declares user activity to help prevent display sleep. That keeps the screen on, but it doesn't replace the input event.
There's a practical trade-off here: Accessibility permission gives the app broad potential influence over input. A transparent utility should explain why it needs that permission, stay visible to the user, and avoid disguising what it's doing. If you're evaluating an existing app, check its permissions and behavior before granting access.
How can Windows reset its input idle counter?
Windows provides GetLastInputInfo to read how long it's been since the last input event. In the Windows 11 tests described here, sending a key-up event for an unassigned virtual-key code reset that counter without moving the pointer.
The project used a code in the 0x97 to 0x9F range, which the author identified as unassigned. The event is a key-up for a key that was never pressed. Because there's no matching assigned key for an application to act on, the intended result is an input signal without a visible character or cursor movement.
In one test, the input-idle value dropped from 144 seconds to 0.3 seconds. That's a measurement for a specific machine and implementation - not a guarantee for every Windows release, configuration, or application. Windows input injection has constraints, so software should verify the result instead of assuming a candidate event works everywhere.
What can block the event?
Windows' User Interface Privilege Isolation (UIPI) can block a process with normal privileges from sending input to a foreground application running with administrator privileges. If an event gets blocked in that situation, the utility may not reset the counter as expected.
The project also tried a zero-distance mouse-move event. It reset idle time in its test, but the developer chose the unassigned key-up approach instead. That's a useful engineering mindset: test multiple candidate signals, compare effectiveness and side effects, and then run checks on the real OS versions you care about.
For a production utility, validation shouldn't stop at one "it worked once" run. Confirm that the idle counter resets, check that the cursor doesn't move, and test common foreground applications. The KeepMeOn project describes using a Windows runner in its GitHub Actions workflow to probe candidate signals. Automated checks don't prove universal compatibility, but they make regressions easier to catch.
When does an input-reset tool make sense?
An input-reset utility can be reasonable for short, predictable breaks - like stepping away for coffee and coming back soon. It's not a substitute for locking your computer when you'll be away for a longer stretch. A status indicator is already imperfect, but keeping it "active" during a long absence makes it less useful to your colleagues.
KeepMeOn's implementation aims to limit that risk. It waits until two minutes have passed without real input, then checks once every 60 seconds. In a seven-and-a-half-minute macOS test, the input-idle counter peaked at 181 seconds - below the roughly five-minute threshold observed in that setup.
It also pauses when the screen is locked or when the computer or display is asleep. The app can optionally pause outside work hours and during a lunch break. Those controls matter more than how clever the synthetic event is: a tool that runs indefinitely would hide a much longer absence than the coffee-break scenario justifies.
A practical decision checklist
Before using or building a utility like this, ask:
- What problem are you solving? If the computer is sleeping during a presentation, use a power-management tool. If the input counter is the issue, a power assertion alone won't solve it.
- How long should this behavior last? Keep it short and explicit. For longer absences, lock the screen and let presence reflect that you're away.
- What are your company's rules? On a managed device, check acceptable-use and monitoring policies. Even if the mechanism is technically simple, changing presence may be prohibited.
- What permissions does it need? On macOS, event posting requires Accessibility access. Understand that permission before granting it, and prefer a visible app with a clear explanation.
- What happens when it fails? Make sure it reports missing permissions, sleep states, or blocked input - so you don't get a false sense that your status is being maintained.
The KeepMeOn project is presented as free and open source under the MIT license. Its macOS version is a native Swift and SwiftUI menu-bar app for macOS 13 or later, and the Windows version is a C# tray app targeting .NET Framework 4.8. The developer says the apps have no account, analytics, or third-party dependencies, and they use GitHub contact only to check for updates (which can be disabled). Those details can help when you evaluate the software, but they don't override workplace policy.
Key takeaway: Pick the mechanism based on what you actually need to change. Power assertions affect sleep. Input events affect input-idle time. And any presence-related workaround should stay clearly limited and policy-compliant.
Conclusion
Keep-awake tools and input-reset tools solve different problems. Caffeinate, Amphetamine, and PowerToys Awake can prevent sleep, but your input-idle counter can still keep climbing. If Teams bases Away status on that counter, that difference is why the usual "keep awake" fix may not work.
In practice, the choice is simple: use a power assertion when you need to prevent sleep. Consider an input event only for a brief interruption, and only when workplace rules allow it. Keep the behavior visible and time-limited, and lock the screen when you leave for longer. That keeps the "presence" signal aligned with what it's supposed to do: help other people understand whether you're actually available.