> ## Documentation Index
> Fetch the complete documentation index at: https://docs.happyuptime.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting

Diagnose monitor false positives, alert silence, Slack issues, and config errors.

# Troubleshooting

## Monitor reports down but the site is up for me

1. **Check which regions failed.** Open the monitor — if only one region failed, it's a network blip, not your service. Configure "alert when N regions agree" if you don't want single-region pages.
2. **Look at the response.** The check detail shows status code, headers, and body excerpt. Often it's a Cloudflare/CDN error page or a `Connection reset` from a stuck pod.
3. **Run an ad-hoc check.** `happy monitors check <name>` runs immediately from all 6 regions. Compare against `curl` from your laptop to spot geo-fencing.
4. **Try `happy speed-test <url>`** for a one-off comparison without creating a monitor.

## Alerts aren't being delivered

1. **Channel paused?** **Alerts → Channels** — channels with 50+ consecutive failures auto-pause. Resume after fixing.
2. **Quiet hours?** Check the rule — quiet hours suppress non-critical alerts during the configured window.
3. **Rule scope?** Rules can be scoped to specific monitors. A new monitor without a rule won't alert. The "Default" rule covers all monitors unless you've narrowed it.
4. **Webhook 4xx/5xx?** **Alerts → Log → click delivery → response body** — most webhook failures are auth or signature mismatches.
5. **Slack `missing_scope`?** Reinstall — usually means a new scope was added since you first installed the app. See [Slack integration](/integrations/slack).

## Slack channel picker is empty

The bot needs to be a member of channels to list them (private channels are always invisible). Either:

- Re-run OAuth and pick the channel during install (auto-invites the bot), or
- `/invite @happyuptime` in the channel from Slack.

## On-call is paging the wrong person

Most likely an override or a fixed shift is in effect. The resolver order is:

```
Override > Fixed Shift > Rotation (gated by Restriction)
```

Check **On-Call → [schedule] → Timeline** for the relevant time window — it shows the resolved person and what rule won.

If it's a timezone problem: layers store TZ explicitly. A schedule in `America/New_York` with handoff at 9 AM hands off at 9 AM ET regardless of the responder's local time.

## Config push: "no diff"

The local YAML matches remote state. To force a re-apply (rarely needed), use `--force`. To see what would push, `happy config push --dry-run`.

## Config push: "would delete N resources"

`happy config push` deletes resources in remote state that are missing from the local file. This is the point of config-as-code, but it's destructive. Always `--dry-run` first. To prevent deletion of a specific resource, add a `# managed: external` comment above it in remote state and it'll be skipped.

## Visual regression alerts on every check

Your baseline is stale. **Monitor → Screenshots → Replace baseline** to update it. Tweak the threshold (default 0.05 = 5% pixel diff) under the monitor's screenshot settings.

## Status page shows "no data"

Components need to be linked to monitors. **Status pages → [page] → Components → click component → Linked monitor**. The component status is computed from the monitor — if the monitor's never been checked, the component shows "unknown."

## My CLI command says "401 Unauthorized"

```bash
happy whoami
```

Confirms the token in use. Common causes:

- Token from `HAPPYUPTIME_API_KEY` env var overriding `~/.happyuptime/config.json`
- Token revoked from **Dashboard → Settings → API Keys**
- Token's project no longer exists (re-run `happy login`)

## Still stuck?

[Email support](mailto:hello@happyuptime.com) with the affected monitor/incident/schedule ID and a rough time window. We can pull check history and alert logs from our side.