Guess who is the competitor for the FogBugz bug tracker:
Of course it's a bug in configuration done by someone from Atlassian, but let's stop laughing and check what might be the final resolution for such type of problems:
- Google / AdWords: couldn't they just check (HTTP 200) any target address passed by theirs customer? It's a very simple change in the service
- Atlassian: automatic HTTP log scan won't be possible as web server hasn't been reached (DNS resolution phase), but 100% bounce rate should raise a warning
Anyway, dealing with such errors in non-systematic way (fixing just this error) is dangerous as further instances are not blocked. It's better to have an automatic process that helps with such errors exposure in the future.
We, at Aplikacja.info believe that bugs should be eliminated systematically i.e. every missed one should have proper effect in process change. The more "sensitive" process (more bugs exposed by the process) the smaller amount of bugs are left in the end. For example coding in PHP with massive refactorings is a trouble-maker (as the language has no static checking included and requires high level of test coverage to uncover every error). Any piece of internal check (only method names + parameter numbers done by lint-like tools) will help a lot there.