It looks like you start grabbing live data from the logs and start with 0 data, but there's up to 1500 lines of logs that you should be able to grab via API. If you aren't using them already, you could use them to seed the initial data state.

Since this app logs into my Heroku account via OAuth, I'd feel best as a user if it enforced HTTPS for all pages:

Max mentioned this, as did Benny @ Timehop. Benny gave these examples:

https://www.youtube.com/watch?v=mT91ns2udyQ
http://code.shutterstock.com/rickshaw/examples/fixed.html

Someone who saw this, who shall remain nameless, thought utilization was somehow involved with memory. Might be clearer to label it "Dyno Utilization". Or possibly "Process Utilization", but I'm not sure that's very clear.

Previous versions had a definition of utilization on the page, and that might be useful to include again.

Looks like the metrics format has changed to be l2met friendly.

2013-03-14T13:10:27+00:00 heroku[web.1]: source=heroku.13355784.web.1.533f14e5-1df6-4108-a550-88330ad749c5 measure=memory_total val=120.26 units=MB

median number on Dashboard is really misleading. It's showing 55ms, but I know avg response is around 350ms.

Runtime metrics just added #'s over the weekend to support the l2met format.

This app has them enabled, but the memory usage isn't working because of the hashes.

Just tried my first deploy of the log2viz app and can't seem to get the callback working. Anyone else running into the error below on heroku or local? I am either able to get this one error or a redirect loop error.

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<errors>
<error>Not found</error>
</errors>

The current tooltip for the "95th percentile" statistic begins with, "The slowest 5% of responses." It could be clarified, "5% of responses are slower than this." or better, just use the definition of percentile, "95% of responses return at least this quickly."

It occurred to me that while having a numeric value for Average and Max is useful to us developer-minded folk, a visual interpretation would likely be quite beneficial to many people.

This might look like a thin bar, the left side indicating 0MB and the far right indicating either 512MB or 1024MB depending on the dyno size. Two markers could be placed on this line to indicate minimum and maximum, which move around upon these metrics being updated. The are of the line between the two might be brighter to indicate relevance.

I say this realizing that we don't have a Min visible right now, but do we have this and it's just hidden? If not, then perhaps the other marker would be the average.

Using this data, in either case, we might even output a concurrent web worker recommendation: "You could fit 4 workers into a single dyno at this rate."

All just thoughts. I just know that people tend to like visuals for this kind of data.

Looks like (as of now, anyhow) it's impossible to create new OAuth clients:

"error":"Sorry, you cannot create OAuth clients at this moment.\nPlease subscribe to the Heroku changelog to be notified when this changes:\nhttps://devcenter.heroku.com/changelog\n"}

^ What I get when attempting the cURL command specified in the readme.

Stethoscope is matching any URL with "/health" in it as a health check:

http://log2viz.herokuapp.com/fake/path/health

Suspect function here:

https://github.com/NZX/stethoscope/blob/master/lib/stethoscope.rb#L142

re: #22 (comment)

Did you drop display of 5xx responses if it's 0? I'd think it would be better to advertise that you would display them if there were any.

Feedback from @sclasen: identify which dyno is using the maximum amount of memory so an appropriate action can be taken.

I'm worried about a dyno entering swap, so I want to know what the max memory used is. That can get masked by using the average of several dynos.

Basically I load http://log2viz.herokuapp.com/app/dashboard and see utilization and throughput as being really low, then wait a bit and watch the numbers climb as you get more data. Perhaps you should either not display any data until you've got enough, or make your calculations based on the amount of time you do have. i.e. extrapolate 10 seconds into a 60s number.

When no data is available, elements have a "loading" class appended to them. Think about initial page display for loading state.

Keith logged in with the wrong account and then couldn't switch.

The 512Mb "max" RAM is hardcoded which doesn't reflect the state of all dynos running on the platform.

I've been keeping a tab open with log2viz running for vault-usage and
noticed that it consistently dies after a few hours. I left it
running with a console open to see if I could get some useful details
which you can see in the attached screenshot. I'm running Firefox
19.0.2 on OS X 10.8.3.

/Users/tel/code/log2viz/app.rb:136:in `[]': invalid number of elements (0 for 1..2)

This is the offending line (app.rb):

data = Hash[ matches[4].split(/\s+/).map{|j| j.split("=", 2)} ]

The process per dyno number is based on

config["UNICORN_WORKERS"] || config["WEB_CONCURRENCY"] || params[:concurrency] || 1

which means that if none of these variables are defined it will just output 1 and this may be wrong (in my case it wrong is since I am running 3 unicorn workers but they are not defined as a config var).

I think a small tooltip will suffice.