Handling "Micro-Interruptions" in Work Sessions (e.g., changing a song, checking the time)

[Or-Ka]

Currently, ActivityWatch is extremely precise in tracking every window change. However, this precision often contradicts the "cognitive reality" of a work session.

For example: While working for 2 hours in Revit, I might spend 15 seconds switching a song on YouTube or 5 seconds checking a system setting. In the current data model, these few seconds of "non-work" activity immediately break the continuity of the work session, resulting in fragmented blocks and an inaccurate (shorter) total of "Work Time."

The Concept:
A professional work session often includes these tiny, non-related tasks that don't actually break the user's focus or the project's time block. We need a way to "absorb" these micro-interruptions into the surrounding work session if they are below a certain duration threshold.

Proposed Feature/Logic:

Interruption Tolerance: Introduce a setting (e.g., "Max Interruption Duration") where any non-work event shorter than X seconds (e.g., 30-60s) does not break a continuous work session.

Gap Filling vs. Activity Filling: Instead of just filling empty gaps where no activity was recorded, the logic should also be able to "swallow" short, unrelated activities that occur between two blocks of the same project/category.

Billing Accuracy: This would allow freelancers to report a realistic "Total Session Time" that isn't penalized by the 10 seconds it took to skip an ad or reply to a quick system toast.

Questions for the community:

Has anyone developed a custom script or a that accounts for these micro-interruptions?bucket-query

Is there a plan to introduce "Fuzzy Logic" or "Tolerance Thresholds" to the visualization/summary layers of ActivityWatch?

[0xbrayo]

Has anyone developed a custom script or a that accounts for these micro-interruptions?bucket-query

This script "floods" the time filling in the microinterruptions and counting them as working hours as long as the events before and after match the work regex. The filling/flooding is also configurable. It is not yet implemented in the visualization of AW though.

[0xbrayo]

it is not yet implement in the visualization of AW though.

It is in now in the dashboard and should be available in the next release. ActivityWatch/aw-webui#775

[wind-mask]

When writing a watcher, I realized that adding a "multi-track" event data model to the bucket might help collect information more accurately—for example, when multiple players or coding agents are running during the same time period.
like:

═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
                                           Time Line →                                                      
    00:00      00:01      00:02      00:03      00:04      00:05      00:06      00:07      00:08      00:09      
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════

Player Bucket ──────────────────────────────────────────────────────────────────────────────────────────────────────
  Player 1    ████--------------------████████████████████████████████████████--------███████████--------------------
  Player 2    ------------████████████████████--------------------████████████████████-------------------------------
  Player 3    ████████████████████████----------------████████████████------------------------███████████████████████
  Player ……
Agent Bucket ───────────────────────────────────────────────────────────────────────────────────────────────────────
  Agent 1     ████████████████████████████████████████████████████████████████████████████████████████████████████████
  Agent 2     ------------████████████████████████████████████████████████████---------------------------------------
  Agent 3     ------------------------████████████████████████████████████████████████████████████████████------------
  Agent ……
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════

[0xbrayo]

I think this should be done as a post processing step, you can have a script that consolidates it into the "multi-track" bucket for visualization or whatever. But for the core AW, the data should be recorded separately.

[wind-mask]

Actually, after rethinking, I realized that from the perspective of a single focus, AW indeed does not need a multi-track model; it can be implemented in the watcher instead.
event like:

{
  "timestamp": "……",
  "duration": ……,
  "data": {
           "key": "value"……
           "sessions": [……sessions]
          }
}