I have to track my time for work. The work timesheet app is ... cumbersome. I heard about an app a while back that would track what you did and enter your timesheet for you. That sounded pretty cool to me!

My AHK script

Sadly, I never did track down that app (so I'm still entering my time manually), but I did write something vaguely similar in AutoHotkey, a Windows scripting language. My AHK script tracks mouse & keyboard activity, and logs active and idle time to a disk file, along with the title of the active window, every fifteen seconds. I load the file in a Vim window and set it to autoupdate. I have a long, complex search expression that highlights (some) "work" activities. (There's a screenshot of such a Vim window attached to this submission, though I didn't replicate my "work-related" search.)

This script, rudimentary though it is, has frequently been very handy in figuring out what I did at the end of a long and busy day.

AHK script limitations

It's okay, but it's not great. It has many limitations and drawbacks.

  • It's Windows-only, on a single machine.
  • It's me only.
  • I had to jump through many hoops to get my Linux shells (in gnome-terminals exported as stand-alone X11 windows to my Windows desktop) to show their $PWD in the window title, so that my script could track my activities, or some semblance thereof, on the many remote servers I work on.
  • That search expression on my Vim window is cumbersome and not flexible enough.

Big goals

This is what I wanted to build:

  • A service in the cloud where you could send activity records.
  • Anyone could use it to track their own activities.
  • Sensors or agents that could run on Windows, Mac OS, and Linux machines, and headless remote Linux servers, and send activity records to the cloud service.
  • The Windows, Mac, and Linux desktop sensors would track mouse & keyboard activity, and active window title. And they might do more, like send a full list of all the apps running every so often, or a full "ps" listing, or whatever else people could think of to track.
  • On a remote server or VM, the Linux sensor would track all of your screen or ssh or tty or tmux sessions, and monitor /proc to see what directories you were active in, what processes you were running, and even what files you had open.
  • A web client that showed you activity updates in real time.
  • In the client, you'd be able to search, save searches as tags, fluidly combine search terms and tags, and generally slice and dice to your heart's content. Wanna know "how much did I work and how much did I goof off"? It could do that. Or, it could tell you exactly how many seconds you spent on each individual client or task or email or whatever.
  • And maybe, just maybe, with all that data, I could build a gateway to that timesheet app. :)

Well, that's what I wanted to build.

Actually written

In the 48 hours I've had, I managed quite a bit less.

  • I have a Go service running on Google App Engine.
  • I have a sensor (written in Go) that runs on Windows only. It tracks your active mouse and keyboard use, and your active window title, and sends them to the GAE service via a REST call.
  • And I have a web client that will show you the last 30 entries that the sensor sent, ordered by time.


As of this writing, the web client does not auto-update, or allow you to retrieve previous entries (though the database does store them all, so all it needs is some client & server updates). It cannot search, much less save searches as tags. And the sensor's detection of active vs. idle time leaves a bit to be desired. (And in the course of all this development, I downloaded the AHK source and found out that AHK has a lot going on under the hood, just to tell me how long it's been since I last pressed a key. My mouse/keyboard tracking is a bit less sophisticated.)

Advantages over AHK

That said, my app already has some advantages over my AHK script. For one thing, I can check it from any browser on any machine. And anyone else can use it, not just me.

Where to find it

You can login there now. (It's a weird URL, I know, but that's GAE for you. When I figure out how to change it, I will.) You have to have a Google ID.

My original GitHub repository from January 2015 is at I pushed pretty regularly throughout the competition.

The sensor

The repo has the Windows sensor, which is a stand-alone Windows program, at To use it, first login to the website, to establish your user ID. Then download the program, open a "cmd" window on your Windows box, and run "sensor ". The sensor prints a line of output every time it sends an entry to the server. Hit "reload" in your browser to see what it's sent lately.


Disclaimers: There is no security yet. Anybody that knows your email address could push events "as you". As the product owner, I have access to all data. It's not something I plan to look at, but I thought I should point it out. And since the product is basically still in beta, I may have to delete the data store at any time. This should not be considered a "ready for production use" service.

Other details

The repo also has all my unit test code. And they all pass, as I write. (But they won't pass for you, because the code that tests the "window title" function looks for a particular window ID, which you of course won't have. But you might be able to figure it out with a little poking around.)

I have a design document where I thought about my app in advance (but wrote no code), and kept some notes of my activity throughout the competition. It's at; feel free to check it out.

My AHK script is here: It inspired my work on this project, but I didn't use any code from it (well, obviously, it's in AHK, not Go! :). And AHK itself is in C++.


This was a solo venture. I didn't collaborate with anyone.

I'd like to thank my wife Roxanne, for being so incredibly supportive this whole crazy weekend. Casey for putting this together. The judges. The Go community, and the Gala competitors that hung out on Slack. The Go authors. Google. Mike Whatcott and Matt Holt at SmartyStreets, the authors of GoConvey, the Go unit testing tool I used.

And a shout out to Charlie Stross, whose book Glasshouse gave me the idea for the name of the project ("Panopticon"). See here and here.

Share this project: