VPS Snaps

Contact

Tell us what broke, and what changed.

One address covers support, billing, and pre-sales. A message with the run log in it is usually answered in a single reply — here is exactly what to put in one.

Email [email protected]

Where to send what

Four addresses, and one of them isn't an address at all — the most common reason people write in can be settled from your own dashboard in under a minute.

Support, sales, everything else

[email protected]

Failed runs, SSH and storage configuration, plan questions, and pre-sales questions about whether VPS Snaps covers your stack. If you are not sure where something belongs, it belongs here.

Plan changes and cancellation

Open your Billing page

No email needed. Upgrades apply immediately and are prorated; downgrades and cancellation take effect at the end of the period you have already paid for. Write to us only if something looks wrong on the invoice.

Privacy and data requests

[email protected]

A copy of your data, correction of anything inaccurate, or deletion of your account. Worth knowing first: backups live in your own storage bucket, so deleting your VPS Snaps account never touches the archives themselves.

Legal and the Terms

[email protected]

Questions about the Terms of Service, or paperwork your procurement team needs before signing off on a new vendor.

Five things that turn four emails into one

Most of the back-and-forth in a support thread is us working out which run you mean and what the machine looked like when it broke. Answer that up front and we can go straight to the cause.

  1. 1

    The run, not just the job

    Open the failed run under Backup History and paste its URL. That one link pins down the exact attempt, its timestamp, and its log — far more precise than the job name.

  2. 2

    The error text, as text

    Copy the failing lines out of the run log rather than screenshotting them. Strings like RequestTimeTooSkewed, NoSuchBucket, or pg_dump: command not found are searchable and each points at a different fix.

  3. 3

    How we reach that machine

    Whether the job runs over SSH to a server we dial into, or through an Agent that dials out to us. The two fail in completely different ways, and the fix rarely transfers.

  4. 4

    What changed since it last worked

    A rotated database password, a rebuilt server with a new host key, a moved storage bucket, an OS upgrade that dropped the Postgres client tools. This is the single most useful sentence in the whole message.

  5. 5

    Whether Test connection passes

    For SSH jobs, hit Test connection on the server's detail page first. If that already fails, the problem is reachability rather than anything to do with the backup itself, and we can skip straight to it.

Copy this shape

Job:        Database backup — "prod-postgres"
Run:        https://vpssnaps.com/app/backup-runs/<id from Backup History>
Connection: SSH server 203.0.113.10   (or: Agent "eu-west-private")
Storage:    Cloudflare R2, bucket "acme-backups"

Error from the run log:
  pg_dump: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432"
  failed: FATAL: role "vpssnaps" does not exist

Last successful run: 3 days ago
Changed since then:  rotated the database password on Tuesday
Test connection:     passes

Never email us a password, an SSH private key, a provider API token, or S3 secret access key. We will never ask for one — everything we need to diagnose a failure is already in the run log, and anything genuinely missing can be added by you in the dashboard.

What happens after you hit send

We don't publish a response-time guarantee, because a number that holds on a Tuesday afternoon and quietly breaks over a bank holiday weekend isn't worth putting on a page. What we can describe is the process.

01

It lands in one inbox

There is no tiered queue and no first line reading from a script. Messages are worked through in the order they arrive, and nothing is auto-closed for going quiet.

02

We read your run log before replying

For a failed backup, the first move is looking at the actual run on our side. That is why the run URL matters so much — it removes a whole round trip of asking which one you meant.

03

You get told which kind of problem it is

Configuration gets you the specific field to change and a link to the guide covering it. A bug gets called a bug, plainly, along with what we intend to do about it.

04

Fixes get written down

Anything that catches more than one person ends up in the Help Center, so the next person finds it without writing to us at all.

Often faster than writing to us

Three places worth checking first — particularly for anything that reads like a configuration question rather than a broken one.

Help Center

Setup guides and troubleshooting with the real commands, config paths, and error strings — including a walkthrough of what to check when a backup fails.

Read more

FAQ

Shorter answers on plans and limits, supported storage providers, who holds your backup data, and what happens to it if you cancel.

Read more

Service status

The API, backup processing, scheduling, and notifications. Worth a glance before writing in if every job stopped running at once rather than just one.

Read more