This lesson's interactive features are locked, please to keep using them
Alerts
Alerts tell you when a monitored condition needs attention. They can come from metrics, logs, or other events. For example, you might want a Slack bot to ping your on-call engineer(s) when:
- Your login failure rate exceeds 5% for more than 5 minutes
- Your password reset endpoint is called 10 times in a single minute
- Your "export all contacts" handler receives more than 3 invalid-password attempts in 30 minutes
When an alert fires, the on-call engineer needs to actually know what to do. They should have documentation or tools that help them:
- Meaning – one sentence explaining the condition
- First steps – check this dashboard, run this query, look at this log
- Common causes – deployment just went out, database connection pool exhausted, third-party API down
- Escalation – who to contact if the first responder can't resolve it
Keep documentation short, or even better, build it directly into your systems. If someone has to read three pages at 3 AM, it won't get read.
Assignment
Individual authentication events are useful during an investigation, but nobody should have to spot an active attack by tailing a log.
Emit structured security alerts when authentication activity crosses a threshold.
Check the first parameter of AuthAlertThreshold.Record in internal/observability/auth_alerts.go. Older starter code expects a string; newer code expects a uuid.UUID. Pass the request ID directly when its type matches. If your request-ID helper returns a uuid.UUID but Record expects a string, pass requestID(request.Context()).String(). You don't need to change the tracker itself.
These local counters model an alerting signal. A production deployment would aggregate events across application instances and route alerts through its monitoring system.
With Bearly Secure still running, run the CLI tests from the project root. Restart the app between each run or submit.