I just checked and they are still there on mine.  You are looking at the Statistics page, and not the My Account page, aren't you?

Or just use Electrum and you don't have to download anything. 

If you haven't already done so, try setting the minimum difficulty to 256 for both, and leave for a few hours to settle down.  On my S3+s this gives a much better result than letting the pool do it dynamically.  Rebooting should not be necessary.

If you look under Settings, you will see your API key.

Have you compared all the settings between the one that works and those that don't?  Checked the worker name is correct?  Have you tried a cold reboot of the router?

Perhaps a factory reset on the defaulters might help before starting again.  If one can connect, the others should also be able to, so perhaps the settings have been mucked around a little too much.  Of course, you are using a different IP address for each miner, and all in the same group as the successful miner and the router?

... which is why I am amused by the pool-hoppers who pile aboard after a couple of blocks are found in quick succession (and irritated by the consequent reduction in payouts per block - yes, I know that that also is subjective, as in theory it should result in more smaller payouts and make no difference overall).

It's not the same thing as jumping ship when a pool is consistently performing below par, as that could indicate an underlying problem, cf. another pool's past issue with a very large miner which did not report correct results.

Looks nice.  I would prefer to see the info about my workers on the dashboard page rather than the pool's hash rate graph.

You set the minimum difficulty in the My Account page on Slush's web site.  Minimum difficulty for each worker will show --- if it hasn't been set specifically; click on Edit for the worker you wish to change, type in the new setting and save.  Give it a few hours for things to settle down.  You are aiming for Slush to report near enough the same hash rate that CGminer reports, but remember that you are likely to see a lower hash rate anyway at peak internet usage times or if the connection routing is iffy.  Try small steps rather than going for broke: in your example I would start with perhaps 75 and see what happens.  I found it also works in BTC Guild.

Would that be 419 blocks?

Two in a row again - that's twice in three days, and they are looking safe.  Excellent.  A real shame about some of the pool hoppers who jumped ship before the first came through.

What degree of foolishness would you assign when the person doing the clicking has never even had dealings with the company named?

I think you may assume that the figure in CGminer is correct.  The figure on Slush's site is back-calculated from results submitted (the site has no way of knowing your true hash rate).  What does CGminer say your difficulty per submitted share is?  You might want to try setting that slightly higher on the web site, e.g. if your difficulty is running at 48, try setting it to 56 and see what happens.  My own S3+ rigs are set to run at 256 minimum difficulty, which gives me better results than letting the pool set it dynamically.

See the previous few posts, as it may be that the front end and back end servers are out of kilter - which sometimes happens - in which case a recalculation could take place when the stats are corrected (booo...)

Otherwise, are they balanced with another pool, or do they have a failover mining site?  In which case, check the other pool.

Failing that, you might try a factory reset, but perhaps waiting to see what happens to the stats is the best option, at least for an hour or two.

Spoilsport, ruining my dreams.
Trouble is, even if you are correct, the hoppers may still come steaming in.  Yes, I know more hashing should mean more smaller payouts, but it doesn't feel any better.

I don't know where it has all gone, but on this one at least it's all the more for us.  Ker-ching!  My estimated reward for the new round is going through the roof; let's hope we get a few more quickly before all the hoppers consult the tarot and tea leaves and pile aboard thinking they can make retrospective gains.

Thinking back, I had a similar issue with both Slush and BTCG when I first fired up my S3+s.  Initially I let the pools set their own difficulty levels, but when I changed it manually to a minimum of 256 for each worker on each pool I started getting better reported hash rates.  Each S3+ is balanced between the two pools, and each is set up as a seperate worker.  Of course, the optimum setting may be different for an S3 and so YMMV, but it could be worth experimenting.

My stats look perfectly ok around that time - nothing outside the normal range (I use the eu.stratum server).  Possibly it was some kind of intermediate routing issue which was not local either to you or the server.

Possibly, but with such a huge amount of kit the risk of something going fzzzzt! even if all the cabling is up to scratch becomes a near-certainty, given that computer manufacturers shave every penny they can by using the lowest spec components they can get away with (e.g. 16V capacitors in a 14V circuit, where I would use 24V or higher) - one of the most common causes of boards letting out the smoke soon after the warranty expires.

That explains it.  Thanks.