Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a section for bad monitoring examples #15

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Added a section for bad monitoring examples #15

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
aff0dbd
Added a section for bad monitoring examples
Jan 29, 2016
2446f6c
Rephrased the section about bad monitoring
Feb 8, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ Backend development best practices
- [HTTP status codes](#http-status-codes)
- [Load balancer health checks](#load-balancer-health-checks)
- [Access control](#access-control)
- [Avoid quick & dirty approaches](#avoid-quick-&-dirty-approaches)
- [Release checklist](#release-checklist)
- [General questions to consider](#general-questions-to-consider)
- [Generally proven useful tools](#generally-proven-useful-tools)
Expand Down Expand Up @@ -420,6 +421,16 @@ The load balancer health check page should be placed at a `/status/health` URL.

The status pages may need proper authorization in place, especially in case they expose debugging information in status messages or application metrics. HTTP basic authentication or IP-based restrictions are usually good enough candidates to consider.

## Avoid quick & dirty approaches

In projects with very limited time and/or budget, one might considers an easy approach to error reporting. One of these approaches is to send automatic email whenever something goes wrong.

In some cases, this might be enough, but in case of high traffic applications email-based reporting can produce unwanted side effects:
* If critical backend API goes down (i.e. some legacy system fails to respond for longer period of time), huge amount of error mails are generated in short period of time.
* Some errors are more critical than others. Reporting _everything_ generates a lot of noise and actual problems might be missed.

For QA email works out just fine, but in PROD this should be avoided.

# Release checklist

When you are ready to release, remember to check off everything on your release checklist! The resulting peace of mind, repeatability and dependability is a great boon.
Expand Down