In my daily blogging expedition I ran across a nicely done / simple example of using the URLMonitor... but right away I noticed a few problems that might leave you scratching your head trying to figure out why the URLMonitor's eggs appear scrambled.

It is true that the AIR URLMonitor can help you determine if you are 'online' or not but really that isn't its primary purpose. As the name implies - it monitors a URL to determine if it is reachable or not. This 'endpoint' can be in the cloud, on an extranet, on your local machine, etc. So... really the URLMonitor should be used and thought of as a means to determine if the endpoints that you use or consume within your application are 'available' or not. I'm not trying to split hairs on the definition... I'm just to make sure that your expectations are properly framed. Here are four items that might help in your quest for blinding URLMonitor awesomeness.

Prove availability of each endpoint
So, Jonnie's example monitors http://www.google.com - and if that is all you are trying to do you should be good to go... but what if your app uses a combination of the search engine and analytics? Assuming that one URL proves that both services are available might cause you headaches.

Not all services are created equally...
Going back to the example, the URLRequest method as "HEAD" fails with a 405 MethodNotAllowed when querying against http://www.amazon.com... reporting that the URL is unavailable; a false negative. Food for thought.

DNS Services?
The URLMonitor can be tricked to think that the endpoint you are trying to monitor is online if the machine uses a service like OpenDNS where URL failures are swallowed and a 'friendly' page of 'recommendations' are returned... along with an HTTP Status Code of 200. Meh.

URLMonitor( urlRequest, acceptableStatusCodes )
If you need to be picky about your status codes... then "DO IT!" and "DO IT NOW!" The acceptableStatusCodes parameter can be -way- helpful for determining what 'available' means.

Users like things to 'just work' no?