Understanding why Teams keeps showing Away — and how a browser tool fixes it — requires understanding three things: how OS idle detection works, how Teams uses it, and what browsers can do to interfere with it.
Part 1: Why Computers Go Idle
Every modern operating system maintains an idle timer — a counter that measures elapsed time since your last qualifying hardware input. On Windows, this is tracked internally and exposed via the GetLastInputInfo() API call. On macOS, it's the IOHIDGetParameter system call. On both platforms, the timer resets only when genuine hardware events are detected: a physical mouse movement, a keyboard press, or a touchscreen tap.
When this timer crosses a threshold — typically 5 minutes on corporate devices, sometimes as low as 90 seconds under aggressive Group Policy — the OS takes action: it dims the display, locks the screen, or enters sleep mode. This is the mechanism that Teams, Slack, and Zoom all monitor.
Part 2: How Microsoft Teams Detects "Away"
Teams Desktop App calls the OS idle API every 60 seconds. When the returned value exceeds 5 minutes (configurable by admins), Teams sets your presence to Away. It also monitors whether the screen is locked — a locked screen always triggers Away status immediately, regardless of the idle timer value.
Teams Web App works differently. Because browsers sandbox web pages from OS-level APIs, Teams Web uses a combination of JavaScript activity detection (mouse and keyboard events within the Teams browser tab) and the Page Visibility API to determine your status. In December 2025, Microsoft added a new option: "Keep my current status when I'm active outside of Teams on the web" — enabling this under Settings → Notifications → Presence allows Teams Web to detect activity in other browser tabs.
new MouseEvent('mousemove')) do not affect the OS idle timer. Windows GetLastInputInfo() counts only real hardware events. This means pure pointer simulation alone is not reliable for Teams Desktop. KeepAwake addresses this with screen-level techniques.
Part 3: KeepAwake's 5 Techniques
Technique 1: Screen Wake Lock API ✅ Most Reliable
The Screen Wake Lock API (navigator.wakeLock.request('screen')) is a W3C web standard that allows a browser page to request the OS keep the display active. When a Wake Lock is held, the OS suppresses all screen-dimming and sleep timers — the same timers Teams monitors. This is the most direct and reliable method available in a browser.
Supported in: Chrome 84+, Edge 84+, Chrome for Android. Requires HTTPS. Not yet supported in Firefox or Safari (they use PiP + Audio fallback). The Wake Lock is automatically released if the tab is closed or the device runs out of battery.
Technique 2: Picture-in-Picture Video Stream ✅ Best for Minimized Browser
KeepAwake creates a 2×2 pixel animated canvas, captures it as a MediaStream via canvas.captureStream(), plays it in a <video> element, and enters Picture-in-Picture mode. The PiP window floats above all other applications — managed at the OS display compositor level, not the browser level.
Because the OS sees an actively playing video, it treats the system as in-use and suspends idle detection. This technique works even when the browser window is fully minimized and is particularly powerful for Teams Desktop users who need their browser backgrounded. It's the recommended technique for the most reliable always-green Teams status.
Technique 3: AudioContext Silent Tone
An AudioContext is created with an oscillator generating a 40Hz tone at near-zero gain (0.0001 volume — effectively inaudible). An active audio context signals to the OS that media is playing, which on most platforms prevents the idle state. This is especially effective on macOS, where audio session activity is a strong idle inhibitor.
Technique 4: Web Worker Heartbeat
Browser tabs are subject to CPU throttling when backgrounded — the browser reduces the frequency of setInterval calls to save battery. Web Workers run in a separate thread and are not subject to this throttling. KeepAwake creates an inline Web Worker (via Blob URL) that fires a heartbeat tick at your chosen interval, reliably triggering the pointer simulation even when the tab has been in the background for hours.
Technique 5: Canvas Animation Loop
A hidden 2×2 pixel <canvas> element runs a continuous requestAnimationFrame loop, redrawing a single pixel every frame. This keeps the browser rendering thread active. While it doesn't directly affect the OS idle timer, it ensures the browser itself never enters a suspended state, which supports the other techniques.
Why Some Techniques Work Better Than Others
The effectiveness of each technique depends on your browser, OS, corporate policies, and whether you're using Teams Desktop or Teams Web:
| Technique | Teams Desktop | Teams Web | Browser Minimized |
|---|---|---|---|
| Wake Lock API | ✓ Excellent | ✓ Excellent | ✓ Works |
| Picture-in-Picture | ✓ Excellent | ✓ Good | ✓ Excellent |
| AudioContext | ✓ Good | ✓ Good | ⚠ Partial |
| Web Worker | Supplementary | ✓ Good | ✓ Excellent |
| Pointer Simulation | Limited* | ⚠ Partial | Limited |
* Pointer simulation does not affect OS-level GetLastInputInfo(). It provides supplementary browser-level activity only.
Honest Limitations
No browser tool can override every corporate security configuration. These scenarios may prevent KeepAwake from working:
- Group Policy forcing screen lock: If your IT department uses Windows Group Policy to force a screen lock after N minutes of OS idle time, this overrides browser-level wake locks entirely. The OS will lock the screen regardless.
- Advanced endpoint monitoring: Tools like Teramind, ActivTrak, or Veriato track keystroke frequency and active application focus — not just idle time. These won't be affected by KeepAwake.
- Firefox and Safari: No Wake Lock API support yet. KeepAwake falls back to PiP + AudioContext + Canvas, which is still effective on most systems but less guaranteed than Chrome/Edge.
- Browser power saving: Some browsers (especially on battery-saving mode) may throttle background tabs aggressively. This is why the Web Worker technique is critical — it's immune to tab throttling.
What to Do If Teams Still Shows Away
- Use Chrome or Edge for Wake Lock API support
- Click Allow when KeepAwake requests Picture-in-Picture permission
- If using Teams Web: enable "Keep my current status when active outside Teams" in Teams Settings → Notifications & Activity → Presence
- Check your Windows Power Settings: set both "Turn off display" and "Put computer to sleep" to Never while KeepAwake is running
- For corporate devices: check if Group Policy is overriding your power settings (IT can confirm this)
Browser Mouse Jiggler vs Hardware Mouse Jiggler: A Technical Comparison
Understanding the technical difference between browser-based and hardware jigglers helps explain why KeepAwake is often more effective for the specific problem of keeping Teams active on managed corporate devices.
A USB hardware mouse jiggler registers as an HID (Human Interface Device) with the operating system and periodically sends physical cursor movement signals. These signals do reset GetLastInputInfo() — that's the genuine advantage of hardware. However, hardware jigglers visibly move your cursor across the screen (disruptive when you're actually working), cost $15–50, require an available USB port (often locked on corporate laptops), and can be flagged by enterprise security tools that monitor for unusual HID device registrations.
A PowerShell mouse jiggler script uses [System.Windows.Forms.Cursor]::Position to move the cursor at OS level — which does affect the idle timer. But it requires PowerShell execution policy permissions (Set-ExecutionPolicy Unrestricted), admin rights, and technically blocks most corporate device policies that set execution policy to Restricted.
KeepAwake takes a completely different approach. Rather than simulating input to reset the idle timer, it uses the Screen Wake Lock API to directly instruct the OS not to start the idle timer countdown at all. The end result — Teams stays green, screen stays on — is the same, achieved through a fundamentally different and more elegant mechanism. No cursor movement, no permissions required, no hardware needed.
The Wake Lock API: How a Website Can Keep Your Screen On
The Screen Wake Lock API is a W3C web standard implemented in Chrome 84+ and Edge 84+. It works through a straightforward browser-to-OS request: when a web page calls navigator.wakeLock.request('screen'), the browser forwards this request to the OS as an application-level wake lock — the same kind of wake lock that Netflix or YouTube uses to prevent your screen from dimming during video playback.
The OS then suppresses all screen-dimming timers and idle detection mechanisms for as long as the wake lock is held. This is not a hack or workaround — it's an intended, documented, standards-based API designed exactly for this use case. The Wake Lock is automatically released when the page is closed, when the browser loses focus (on some platforms), or when the device battery reaches a critically low level.
For Teams Desktop, this means that while KeepAwake is running with an active Wake Lock, the OS never reports an idle state — so Teams never receives the signal to switch your status to Away. The screen stays on, the OS stays "awake," and your Teams status stays Available indefinitely.
Frequently Asked Technical Questions
Does KeepAwake move my mouse cursor? No. None of KeepAwake's five techniques visibly move your cursor. The pointer simulation that some browser jigglers use dispatches synthetic mouse events within the browser — these don't affect the OS idle timer and aren't used by KeepAwake for the primary keep-alive function. KeepAwake achieves OS-level idle prevention without any cursor movement whatsoever.
Can IT detect I'm using it? KeepAwake appears in your system's process list as a browser tab — indistinguishable from any other website you might have open. Standard monitoring tools that check idle status and screen lock won't trigger. Advanced behavioral monitoring tools (keystroke trackers, screenshot tools) operate at a different level and aren't affected by any browser-based solution. We recommend using KeepAwake for legitimate purposes and being aware of your organization's policies.
Why do I need 5 techniques? Wouldn't one be enough? In an ideal world, Wake Lock alone would be sufficient. In practice, different browsers support different APIs (Firefox has no Wake Lock yet), different corporate policies restrict different browser features, and different OS configurations respond differently to each signal. Running all five techniques simultaneously provides defense in depth — if one technique isn't supported or is suppressed by a corporate policy, the others continue working. The Web Worker heartbeat, in particular, is immune to the aggressive background tab throttling that some browsers apply, ensuring the techniques continue reliably even after hours of background operation.