There can be several causes of this
1) some times exchange just does not return request  - in this case the best option we have to assume the last available data as actual
the problem can be on exchange side - btc-e was ddos'ed or our hosting did not get connectivity.

2) in case of gox - we use quite complex logic for stream api client wich accounts for several cases:
  - stream api can connect us but does not subsribe to any channel in this case we need to detect that stream is dead after some timout and reconnect
  - if we could not reconnect for 15 minutes we force orderbook reinitialization - request full ordrbook via http
  - also gox can disconnect/reconnect us arbitrarily often and each time we connected again and subscribed we need to reinitialize orderbook state requesting full orderbook via http but we cannot request too often otherwise we will be  blocked by gox. thus we maintain hysotry of requests for each currency and wait in timeout if necessary some times for on hour and rarely for 24 hours.

all those timeouts is subject to changes and tweaks cause mtgox every time shows different and new patterns of how their engine can behave.

in all those cases we use last know state of orderbook to be able to assign trades to bid or aks side.

3) bitcoincharts can:
  - be down
  - we just do not connection to bitcoincharts
  - bitcoincharts delays some trades  - in this case after some time bitcoincharts cn send all dealyed trades and if our application was still up it sorts all of them by timestamp to its time slot and assigns bid/ask side, but if our application happend to restart due its own uncought exceptions then delayed trades could not come to us at all.

So if orderbook state is not changing you can see flat line.
If trade time is increasing then trades are not coming.

so you can imagine that thigns are a bit complex here.

thank you for your attention to those details