0 8 * * *     df -h | awk '/^\// && $5 > 95 { print "missing space", $0 }'

and ensure e-mail to this user is forwarded to you then you will see e-mail when occupied space is higher than 95% on any disk.

Pretty simple.

Note: all uptime buttons and images below are generated in real-time, you can click on images / baners to see reports with details directly from site-uptime.net.

MySpace

MySpace uptime

Facebook

Facebook uptime

Twitter

Twitter uptime

As you can see the “winner” in this category is: Twitter!

Site-uptime.net

site-uptime.net is a service that continuously monitors websites and allows to configure email / SMS notifications on downtime. May be helpful for professionals who care about accessibility and uptime of their services.

Site: http://twitter.com is down ('502 Bad Gateway')

Looked at main Twitter page and saw this picture:

I checked that Twitter responds very slowly and randomly shows “over capacity” page. You can see details on site-uptime public report. Here’s response graph from last days (measure interval 15 minutes, HEAD requests):

UPDATE (2010-04-15): after few weeks the situation is getting worse:

Bardzo ciekawe. Po kolejnej próbie otwarcia strony dostaję następujący komunikat serwowany z url-a: http://www.goldenline.pl/offline.html:

Przerwa zapewne jest planowa, oczywiście obiecuję trzymać kciuki za obsługę portalu

Oto co zobaczyłem w środku pliku HTML:

<a href="http://www.goldenline.pl"><img src="logo_big.gif" alt="Praca w GoldenLine" /></a>

Czytaj “mamy problemy ze stabilnością, być może jesteś kompetentnym adminem, żeby nam w tym pomóc, zapraszamy” . W innym:

<!--<strong>GL wraca o 05:00 jeszcze szybszy  </strong>-->

Dość duże to okno serwisowe

UPDATE (2010-02-08): sytuacja została opanowana przed 5-tą jak widać na wykresie:

One week HTTP measurement

I’m using another service: site-uptime.net to record and analyse statistics from running Twitter website. Measurements are performed every 15 minutes using HEAD requests, total time of receiving response (excluding DNS resolution time) is collected. Here are the results showing data collected from eight days using station from Poland:

You can see time response spikes located every ~10 PM GMT +2. Are they related to server load or network? To check that we can see measurements retrieved using station from Chicago, USA:

The picture is quite different. Seems the traffic on network connection to Europe causes higher access time. Let’s see if it has impact on speed of serving responses:

Not so bad. ~90% of requests are served under 1 second, it’s very good result. Average response time is 650 ms, minimal: 370 ms . Note no downtimes in January – a good result.

Where’s Twitter located?

Let’s see where twitter.com web server is located:

$ mtr twitter.com
(...)
 6. te3-1.lonse1.London.opentransit.net        0.0%    27   48.2  48.8  47.8  49.8   0.5
 7. xe-3-1.r01.londen03.uk.bb.gin.ntt.net      0.0%    27   48.6  96.8  48.1 244.9  67.3
 8. ae-1.r22.londen03.uk.bb.gin.ntt.net        0.0%    27   50.3  50.9  48.9  72.3   4.6
 9. as-0.r20.nycmny01.us.bb.gin.ntt.net        0.0%    27  131.7 129.7 127.7 132.7   1.4
10. ae-0.r21.nycmny01.us.bb.gin.ntt.net        0.0%    27  124.1 125.3 122.6 136.4   2.8
11. as-0.r20.chcgil09.us.bb.gin.ntt.net        0.0%    27  141.4 146.0 139.8 172.6   9.1
12. ae-0.r21.chcgil09.us.bb.gin.ntt.net        0.0%    27  144.7 147.4 143.7 181.2   7.7
13. as-5.r20.snjsca04.us.bb.gin.ntt.net        0.0%    27  199.7 210.2 199.7 281.7  18.4
14. xe-1-1-0.r20.mlpsca01.us.bb.gin.ntt.net    0.0%    27  203.7 204.2 198.9 242.5   8.0
15. mg-1.c20.mlpsca01.us.da.verio.net          0.0%    26  200.1 200.2 195.2 207.2   2.5
16. 128.241.122.117                            0.0%    26  196.7 197.6 193.1 209.1   2.7
17. 168.143.162.5                              0.0%    26  201.7 226.6 196.2 278.5  28.2
18. 168.143.162.36                             0.0%    26  196.4 212.4 195.8 261.2  21.0

Far from Europe (200 ms). geoiptool service will show more details:

Servers are located in Colorado. The best times I can get from USA is ~110 ms (tested from Newark). Seems Europe Twitter users are in worse position, but the kind of service (short messages, easily compressable text content) works fine with such packet delays.

About Measurement Service

site-uptime.net allows you to measure any website and notify you on downtimes. You can check how your website is visible for customers 24/7 and are able to track any problems (even if they appear out of your local business hours).

However, such random problems may show efficiency problems with your site (timeouts). You should check carefully what’s hidden behind them (web server error log, if available).

Today I’d like to share some observations on web applications speed. My monitoring network checks almost one thousand of URL addresses and few interesting pictures are created here.

Lets see sample monitoring results from random URL (one week measurment): http://forum.magicsquad.eu (located currently in webh.pl hosting provider):

As you can see typical site response time is almost four seconds! (DNS resolution time excluded) Measurment is performed from Cracow, Poland. Let’s see results from Chicago, USA:

Similar picture (slightly slower ping times visible). We have two possibilities here:

• Script is clumsy (PHPBB)
• Hosting is overloaded / improperly configured

Long term analysis

Let’s see statistics generated by site-uptime.net (monitoring station in Poland):

As you can see performance degradation (80% -> 10% responses under one second) started 5 months ago!. No one noticed that average page loading drops suddenly (no change of hosting provider since then!).

You can reach current public report for monitored station here.

Conclusions

• I suggest to monitor site performance and availability, especially if you are making money from them
• Sometimes fix is at your fingertips (if you know the problem details)