Monitoring, health checks and alerts

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:

# 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 <[email protected]>, and replies go to [email protected].

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.

Notification settings

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

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 and High memory or swap usage.
4. If it's still down and you can't see why, email [email protected] with the instance name and the time of the alert. Writing a support request that gets solved fast has a template.

More in Instance health alert: services 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.

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.

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.
• Cron run history on the Cron tab and in cron.job_run_details. See Monitoring and debugging cron jobs.
• Service logs over SSH on Business and Enterprise, with sudo supahost-logs. See SSH access and direct Postgres.
• Postgres statistics such as pg_stat_statements and pg_stat_activity, from Studio's SQL editor. See Query performance and EXPLAIN.

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.

Related

• Instances
• Limits reference
• Shared responsibility