# Monitoring, health checks and alerts

> How SupaHost checks your instance every minute, when downtime and usage alert emails are sent, how to set notification preferences, and how disks grow automatically.

Source: https://supahost.app/docs/platform/monitoring · Updated 2026-11-11

SupaHost watches every instance for you. It checks health about once a minute, emails you when the instance goes down and when it recovers, warns you before you run through a quota, and grows the disk before it fills. This page explains each of those and what you can tune.

## Health checks

On every pass, about once a minute, SupaHost checks that:

1. the instance answers over HTTPS at its root address,
2. the SupaHost agent on the VM reports itself ready, and
3. the agent has reported in within the last 10 minutes.

If all three pass, the instance is healthy. After **3 failed checks in a row**, about 3 minutes, the instance is marked **down** and a downtime email goes out. The first good check after that marks it **recovered**, and a recovery email follows.

Each project's readiness is checked separately on its Auth health endpoint. You can call the same endpoints from your own uptime monitor:

```bash
# Instance: no key needed
curl -s https://acme.supahost.space
# {"instance":"acme","status":"ok"}

# One project's Auth service
curl -s -H "apikey: $SUPABASE_ANON_KEY" \
  https://app-one.acme.supahost.space/auth/v1/health
```

An outside monitor is worth having alongside SupaHost's: it tests the path your users take, from where they are.

## Alert emails

Alerts are sent from `SupaHost <notifications@supahost.app>`, and replies go to supahost@volods.com.

| Email | When it's sent |
|---|---|
| Instance down | After 3 failed health checks in a row |
| Instance recovered | On the first good check after being down |
| Usage alert | When database, file storage or monthly egress crosses your threshold, and again at 100% |
| Upgrade available | Once per new release, if automatic upgrades are off |
| Upgrade done | When an upgrade finishes |
| Restore done or failed | When a restore ends |
| Import done or failed | When an import from Supabase Cloud ends |
| New sign-in, access token created | Security events on your account |
| Weekly summary | Mondays between 08:00 and 10:00 UTC, if you opt in |

Usage alerts compare against your plan plus any add-ons. Each one fires once per level per month, so you get one warning at your threshold and one at 100%, not a daily reminder. See [Quota alert emails and going over](/kb/quota-alerts).

## Notification settings

Open **Dashboard → Settings → Email notifications**. The seven rows cover:

| Emails | Default |
|---|---|
| Usage alerts | On, at 80% (choose 80%, 90% or 100%) |
| Downtime alerts | On |
| Upgrade emails | On |
| Weekly summary | Off |
| Product news | Off |
| Billing and invoices | Always on |
| Security | Always on |

**Also send alerts to** takes up to 5 extra email addresses. Add your on-call address or a shared team inbox, so a downtime alert doesn't sit in one person's mailbox.

## What to do when you get a downtime alert

1. Check whether it's still down: `curl https://acme.supahost.space`.
2. On Business, SSH in and run `sudo supahost-status` to see which containers are running and how much memory and disk is in use. Then look at the logs for the service that's struggling with `sudo supahost-logs <project> <service>`.
3. Look for a cause on your side: a heavy query, a runaway cron job, or a traffic spike. See [High CPU usage on your instance](/kb/high-cpu) and [High memory or swap usage](/kb/high-memory).
4. If it's still down and you can't see why, email supahost@volods.com with the instance name and the time of the alert. [Writing a support request that gets solved fast](/kb/support-requests) has a template.

More in [Instance health alert: services unhealthy](/kb/instance-unhealthy).

## Disk autogrow

The disk on your VM grows by itself, online, with no restart. When it reaches 60% used, it's resized to whichever is larger: 1.5 times its current size, or twice the space in use.

| Plan | Starting disk | Maximum |
|---|---|---|
| Builder | 50 GB | 150 GB |
| Pro | 100 GB | 350 GB |
| Business | 200 GB | 700 GB |
| Enterprise | 400 GB | 2000 GB |

The maximum goes up with add-ons: by the size of any file storage add-on, plus twice the size of any database add-on. The disk never shrinks, including when you change to a smaller plan.

The disk is separate from your billing quotas. Usage alerts are about the database and file storage you're billed for; autogrow is about making sure there's physical room for them. See [Usage, quotas and add-ons](/docs/platform/usage).

## Logs and metrics

What's available today:

- **Edge Function logs** on the Functions tab, filterable by function and refreshed every 10 seconds. See [Logs and debugging](/docs/functions/logs).
- **Cron run history** on the Cron tab and in `cron.job_run_details`. See [Monitoring and debugging cron jobs](/docs/cron-queues/monitoring-jobs).
- **Service logs over SSH** on Business and Enterprise, with `sudo supahost-logs`. See [SSH access and direct Postgres](/docs/platform/ssh).
- **Postgres statistics** such as `pg_stat_statements` and `pg_stat_activity`, from Studio's SQL editor. See [Query performance and EXPLAIN](/docs/database/query-performance).

Not available yet: the project **Logs** tab (searchable Auth, API, Storage and Postgres logs) and **Live metrics** charts for CPU, memory and disk on the Instance page are both marked coming soon. Studio's Logs and Reports pages are also turned off; see [Studio Logs and Reports pages are missing](/kb/studio-logs-reports-missing).

## Related

- [Instances](/docs/platform/instances)
- [Limits reference](/docs/platform/limits)
- [Shared responsibility](/docs/security/shared-responsibility)