New product: WhatTheDeploy - Deploy Tracking

A common thread through every place I’ve worked is the following conversation:

Client/Boss: “Hey, any idea why our page views dipped in mid-April?”

Me: “Hey, guys, did we deploy anything in mid-April?”

Devs: “¯\(ツ)/¯”

Then comes the frantic digging through GitHub commits - which don’t always match deploy dates - to try and find a culprit.

After a spate of this conversation at the day job and in a pique of frustration, I started building WhatTheDeploy - a deploy tracking app that tells you exactly what changes were deployed and shows you what the site looked like at the time. All timestamped, with numbers of relevant commits, all the relevant changes, who contributed and responsive screenshots of N pages of your site.

That’s the core of the idea. Later, I’d like to to look not just at what deployed and how the deploy looked, but what that deploy did - to your metrics, to your error rate, to your customer support inquires, etc. But for now, that’s the idea.

I’ve been working on it nights and weekends for a few weeks now and just launched an early landing page for it yesterday.

The link (in case you missed it earlier):

It looks okay, but could you have a few more graphics up? Something that shows visually how the tool will help. You have a image there, but I have no idea what it’s about.

Also, why just Github? I don’t have any statistics, but do all webby type companies use Github?

What is that, a Mom’n’Pop shop? Ever heard of Release Management?

It is fine you’re trying to fix someone’s screw-ups… but if I had this problem I’d invest money into building the proper RM process rather than try and figure out who has pushed something into prod and why – when the damage is already done.

And the amateurs handling their PROD like this are not going to pay, anyway. They do not care.

1 Like

@shantnu It’s early days. As for GitHub, for who I have in mind, that’s where they’d be. Also handily includes a robust API that lets me do a host of tricks and ease the onboarding.

@rfctr Less the immediate breakage. You find that out and fix it real quick. The use case here (one of several) is more subtle breakage. Like when analytics dips by 30% after a certain date.

Other use cases:

When did X feature launch?
When did that redesign launch?
How many times did we deploy last month?
Release notes (easy creation of is a later feature idea)

So on and so forth.

1 Like

I believe this is a good free open source product to add to one’s portfolio, but I doubt it can ever be sold.

All of those are covered by RM discipline. It is better pro-actively prevent an issue than re-actively trying to fix it.

How it goes? “There are no technical solutions for organizational dis-functions” or something like this.

You look at the spreadsheet (Google Sheet) and see the list of deployments and their updated artifacts.

If you generate such a spreadsheet, it may help… not sure how much though. The biggest pain in RM is preparing for the deployment. No wonder some “agile” teams prefer not to do it at all.

Quick update on this (I need to write a longer blog post on it at some point):

In light of a change in my situation, I flipped the beta period open to anyone ( and it somehow made it’s way to the front page of Hacker News.

Thousands of visitors, 40 or so accounts created, 3 sites initiated, zero deploys as yet.

Likely just lookie-loos, but we’ll see where it goes.