Set Up Backups & Monitoring

This tutorial configures automated backups and uptime monitoring for your Temps instance. By the end, your data will be backed up to S3 on a schedule, you will receive alerts when something goes down, and you will know how to restore from a backup.

What you will build

By the end of this tutorial, you will have:

• An S3-compatible storage bucket connected to Temps for off-site backups
• A manual backup of your Temps database and all managed services
• An automated backup schedule that runs nightly
• A notification channel (email, Slack, or webhook) for alerts
• An uptime monitor that checks your application every 60 seconds
• Experience restoring from a backup

Time required: approximately 20 minutes.

What this tutorial covers and does not cover:

Prerequisites

You need:

• A running Temps instance with at least one deployed project (complete Your First Deployment first)
• S3-compatible storage — any of the following:
  • AWS S3 bucket
  • MinIO instance (self-hosted)
  • DigitalOcean Spaces
  • Cloudflare R2
  • Any S3-compatible object storage
• Credentials for your S3 storage: access key ID, secret access key, bucket name, region, and endpoint URL (for non-AWS providers)

Connect S3 storage

Temps stores backups in S3-compatible object storage. You need to connect a storage source before you can create backups.

1. In the Temps dashboard sidebar, click Settings (at the bottom)
2. Find the Backups section
3. Click Add S3 Source
4. Fill in your storage details:

Click Save. Temps validates the connection by checking bucket access. If validation fails, verify your credentials and ensure the bucket exists.

Run your first backup

With storage connected, run a manual backup to verify everything works.

1. On the Backups settings page, find your S3 source
2. Click the Run Backup button (or use the actions menu)
3. Select Full as the backup type

Temps starts the backup immediately. The process:

1. Temps database — The internal PostgreSQL database (with TimescaleDB extension) is backed up first. Temps uses WAL-G for efficient streaming backups when available, falling back to pg_dump otherwise.
2. Managed services — Every managed service you have provisioned (PostgreSQL databases, Redis instances, S3 storage) is backed up individually.
3. Metadata — A metadata.json file is generated with checksums, sizes, timestamps, and service inventory.
4. Upload — Everything is uploaded to your S3 bucket and the backup index is updated.

You can watch the progress on the page. When the status changes to Completed, your first backup is done.

Verify the backup

Check that files were written to your S3 bucket. The backup is stored at:

{bucket_path}/backups/{YYYY}/{MM}/{DD}/{backup-uuid}/
  ├── backup.sql.gz       # Temps database dump (gzip compressed)
  ├── metadata.json        # Checksums, sizes, timestamps
  └── ...                  # External service backups (if any)

There is also an index file at {bucket_path}/backups/index.json that lists all backups.

Verify from the CLI

If you have the Temps CLI installed, you can list backups directly from S3:

bunx @temps-sdk/cli backup list \
  --access-key-id YOUR_ACCESS_KEY \
  --secret-access-key YOUR_SECRET_KEY \
  --bucket-name your-backup-bucket \
  --bucket-path backups \
  --region us-east-1

For non-AWS providers, add --endpoint and --force-path-style:

bunx @temps-sdk/cli backup list \
  --access-key-id YOUR_ACCESS_KEY \
  --secret-access-key YOUR_SECRET_KEY \
  --bucket-name your-backup-bucket \
  --endpoint https://your-minio-server:9000 \
  --force-path-style

Create a backup schedule

Manual backups are useful for one-off situations (before a migration, before an upgrade). For day-to-day protection, set up an automated schedule.

1. On the Backups settings page, click Add Schedule
2. Configure the schedule:

Click Create. The schedule starts immediately — the next backup will run at the time specified by your cron expression.

Recommended schedules

Disable or enable a schedule

You can pause a schedule without deleting it. On the Backups page, use the toggle or actions menu to Disable or Enable a schedule. Disabled schedules retain their configuration and history but do not run.

Set up a notification channel

Before setting up monitoring, configure where Temps should send alerts. Temps supports three notification channels: email, Slack, and webhooks.

Option A: Email notifications

1. In the sidebar, click Settings
2. Find the Notifications section
3. Click Add Provider and choose Email
4. Configure your SMTP server:

Option B: Slack notifications

1. Create a Slack Incoming Webhook for the channel you want alerts in
2. In Temps, click Add Provider and choose Slack
3. Paste the webhook URL (must start with https://hooks.slack.com/)
4. Optionally set a channel name for display purposes

Slack notifications include color-coded attachments: red for errors, orange for warnings, blue for informational.

Option C: Webhook notifications

For integrations with Discord, PagerDuty, or any HTTP endpoint:

1. Click Add Provider and choose Webhook
2. Enter the URL of your webhook endpoint
3. Optionally configure:
   • HTTP Method — POST (default), PUT, or PATCH
   • Headers — Custom headers for authentication (e.g. Authorization: Bearer your-token)
   • Timeout — Maximum wait time in seconds (default: 30)

Webhook payloads are JSON:

{
  "id": "notif_abc123",
  "title": "Backup Failed",
  "message": "Nightly backup schedule 'production-daily' failed",
  "type": "error",
  "priority": "high",
  "severity": "error",
  "timestamp": "2026-02-28T02:00:15Z",
  "metadata": {
    "schedule_id": 1,
    "schedule_name": "production-daily",
    "backup_type": "full"
  }
}

Test your notification channel

After creating a provider, click the Test button. Temps sends a test notification to verify the connection works. You should receive a test message within a few seconds.

Configure notification preferences

Temps lets you fine-tune what triggers notifications. In Settings > Notifications > Preferences, you can control:

• Backup notifications — failures (enabled by default), successes, S3 connection issues, retention violations
• Domain notifications — SSL certificate expiration (30 days before), domain expiration, DNS changes
• Runtime notifications — deployment failures, build errors, runtime error spikes
• Weekly digest — a summary email sent every Monday at 9 AM with deployment stats, error trends, and performance metrics

Create an uptime monitor

Uptime monitors check your application's health at regular intervals and alert you when something goes down.

1. Open your project in the dashboard
2. Click Monitors in the project sidebar
3. Click Add Monitor
4. Configure the monitor:

Click Create. Temps runs the first check immediately and then continues at the interval you specified.

How health checks work

Each check:

1. Sends an HTTP GET request to the monitor URL
2. Waits up to 10 seconds for a response (within a 30-second client timeout)
3. Retries up to 3 times with exponential backoff (100ms, 200ms, 400ms) before marking as failed
4. Maps the response to a status:

Failure threshold and incidents

A single failed check does not trigger an alert. By default, Temps requires 2 consecutive failures before creating an incident. This avoids false alarms from network blips.

When an outage is confirmed:

1. The monitor status changes to Down
2. An incident is created with severity based on the failure type (Minor for degraded, Major for down)
3. A notification is sent to all configured channels
4. The incident appears on the project's status overview

When the monitor recovers:

1. The monitor status returns to Operational
2. The incident is automatically resolved
3. A recovery notification is sent

View uptime history

On the Monitors page, each monitor shows:

• Current status — Operational, Degraded, or Down
• Response time — Average, P50, P75, P95, P99 percentiles
• Uptime history — Time-bucketed data showing operational/degraded/down periods
• Incident history — All past incidents with severity, duration, and resolution time

Simulate a failure

To verify your monitoring and notification setup is working end-to-end, you can temporarily break your application and watch the system respond.

Option 1: Stop the container (recommended)

If you have SSH access to your server:

# Find your application's container
docker ps | grep your-project-name

# Pause it temporarily (does not destroy it)
docker pause <container-id>

Wait for 2-3 minutes (two check intervals). You should:

1. See the monitor status change to Down in the dashboard
2. Receive an outage notification on your configured channel
3. See an incident created in the project's Monitors section

Now resume the container:

docker unpause <container-id>

Within one check interval (60 seconds), you should:

1. See the monitor status return to Operational
2. Receive a recovery notification
3. See the incident automatically resolved

Option 2: Deploy a broken version

Push a commit that returns a 500 error from your health endpoint, deploy it, wait for the alert, then fix and redeploy. This tests the full loop including deployments, but takes longer.

Restore from a backup

The point of backups is restoring from them. Test this now while everything is working, so you are prepared if you ever need it for real.

Restore via the CLI

The CLI is the primary way to restore backups. It handles downloading from S3, decompressing, and restoring both the Temps database and all managed services.

Step 1: List available backups

bunx @temps-sdk/cli backup list \
  --access-key-id YOUR_ACCESS_KEY \
  --secret-access-key YOUR_SECRET_KEY \
  --bucket-name your-backup-bucket \
  --region us-east-1

Note the backup-id (UUID) of the backup you want to restore.

Step 2: Restore the full backup

bunx @temps-sdk/cli backup restore \
  --access-key-id YOUR_ACCESS_KEY \
  --secret-access-key YOUR_SECRET_KEY \
  --bucket-name your-backup-bucket \
  --region us-east-1 \
  --database-url "postgres://user:password@localhost:16432/temps" \
  --backup-id YOUR_BACKUP_UUID

This command:

1. Downloads the backup from S3
2. Decompresses the database dump
3. Restores the Temps PostgreSQL database using pg_restore
4. Restores all managed service backups (PostgreSQL databases, Redis instances, etc.)

Step 3: Restart Temps

After a restore, restart the Temps service to pick up the restored data:

sudo systemctl restart temps

Restore a single managed service

If you only need to restore one specific service (e.g. a PostgreSQL database that was corrupted), use restore-service:

bunx @temps-sdk/cli backup restore-service \
  --access-key-id YOUR_ACCESS_KEY \
  --secret-access-key YOUR_SECRET_KEY \
  --bucket-name your-backup-bucket \
  --region us-east-1 \
  --backup-id YOUR_BACKUP_UUID \
  --service-name my-postgres-db \
  --encryption-key YOUR_TEMPS_ENCRYPTION_KEY

The --encryption-key is needed because managed service connection credentials are encrypted at rest. You can find it in your Temps configuration.

What you have accomplished

Your Temps instance now has a complete protection layer:

Additional protections that Temps runs automatically in the background:

• Disk space monitoring — Alerts when disk usage exceeds 80% (configurable threshold). Escalates to critical at 95%.
• Backup failure alerts — High-priority notifications if a scheduled backup fails.
• SSL expiration warnings — Notifications 30 days before certificates expire.
• Weekly digest — A summary of deployments, errors, and performance sent every Monday.

What to explore next