WebsiteSave.com - What changed on your website? Know what to restore.

Hey Product Hunters! 👋

I'm the maker behind WebsiteSave.

I built WebsiteSave around a problem that feels surprisingly simple:

Having a backup is great. Knowing which backup to restore when something goes wrong is even better.

Websites change constantly — updates, configuration changes, new files, security issues, and unexpected problems can all happen without much warning.

That’s why WebsiteSave is built around four things:

Protect → Detect → Understand → Recover.

WebsiteSave combines automated website backups with security and website-health insights, giving you more context around what changed and which recovery point may be useful when you need to recover.

🎉 Product Hunt early-bird offer: 25% OFF all WebsiteSave packages

Use code PHUNTERS at checkout.

If you manage a website — whether it's your own site, a client site, or multiple websites — I'd genuinely love your feedback.

What is the biggest pain point you've experienced with website backups or recovering a website?

Thanks for checking out WebsiteSave and supporting the launch! 🚀

A question came up from someone who checked out our Product Hunt launch:

“Do you have a public status page where users can check uptime and reliability?”

It's a good question, especially for a service responsible for website backups.

We currently show service status directly in WebsiteSave, and each backup job reports its progress and outcome in the dashboard. Failed jobs are logged and surfaced to the user rather than simply disappearing into the background.

We also deliberately don't expose our infrastructure to third-party uptime-monitoring systems. WebsiteSave uses a distributed architecture, with internal services communicating over TLS, and we don't make the underlying infrastructure publicly accessible for external probing.

For us, there's an important distinction between:

“Can an external service ping something?”

and

“Is the backup system actually processing and completing jobs correctly?”

The latter is what we want users to be able to see.

We're also continuing to improve how we expose operational information to users without unnecessarily exposing the underlying infrastructure.

Curious what other SaaS products do here:

Do you prefer a traditional public status page, or do you think service-specific health and job reporting is more useful?

Another question came up about the data encryption. Yes all of the data is encrypted with AES-256. Decrypted in memory and as soon the restore of a specific file complete, it gets removed from the memory instantly.