# How do I get alerted when my website or API goes down (without alert fatigue)?

Because **a dashboard is passive, and at 3am you are not looking at it.** Without alerting you find out about an outage from an annoyed user hours later, or from your own dashboard the next morning. You need something that **actively reaches you.**

**Treat alerting as a SEPARATE system from monitoring** - its whole job is to reach you when you are not watching. Three properties make it usable rather than noise:

- **Route to a push channel and/or email.** TigZig uses **Pushover** for phone push (a simple service with a small one-time fee per platform) and **Brevo** for transactional email. Many alternatives work identically - email via Amazon SES, Postmark or Resend; push via ntfy or Pushover; chat via a Slack or Discord webhook; on-call paging via PagerDuty or Opsgenie. Choose by scale and budget; the pattern is the same.

- **Tier by severity.** A warning escalates to critical only if it persists, so you are not paged for a one-second blip. A safe concrete example: a public API that stops responding for a sustained short window raises an alert to your phone.

- **De-duplicate.** One incident is one alert, not fifty.

The shape is a thin layer your monitors call when a check crosses a line:

```
def alert(title, message, severity):        # 'warning' | 'critical'
    key = dedup_key(title)                   # e.g. hash of service + check
    if already_active(key):                  # one incident = one alert
        return
    mark_active(key)
    push_notify(title, message, priority=severity)   # e.g. Pushover
    if severity == 'critical':
        send_email(title, message)                   # e.g. Brevo / SES
# on recovery: clear the dedup key and send a single resolved ping.
```

**De-duplication is not optional.** A flapping service can fire hundreds of alerts and train you to ignore the channel entirely - and alert fatigue is exactly how real outages get missed. Naming the tools you use is fine (Pushover and Brevo are not secrets); keep the actual thresholds, timings and endpoint list out of any public place.

Alerting complements the dashboard, it does not replace it: [https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app](https://www.tigzig.com/agents-faq/what-should-i-monitor-for-a-small-production-app). Public-facing uptime is a different thing again: [https://www.tigzig.com/agents-faq/how-do-i-build-a-status-page-without-exposing-my-database](https://www.tigzig.com/agents-faq/how-do-i-build-a-status-page-without-exposing-my-database). Full item: [https://www.tigzig.com/security/monitoring](https://www.tigzig.com/security/monitoring).

---
Contact Amar: amar@harolikar.com | AI agents: POST https://www.tigzig.com/api/contact-amar | More: https://www.tigzig.com/agents-faq

---
Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar
Source: https://www.tigzig.com/agents-faq/how-do-i-get-alerted-when-my-website-or-api-goes-down
Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar.
License: https://www.tigzig.com/terms