See what your Teams meetings cost — free, personal, no setup.
Last updated: September 2026
This page describes how MeetingMinder recovers from an outage or data-loss event — in plain terms, matching the actual infrastructure the service runs on today.
MeetingMinder runs on Microsoft Azure: a stateless application tier (Azure App Service) plus an Azure SQL database holding all persistent data. Because the application tier holds no state of its own, recovering the service is mainly about the database — the application itself can be redeployed from source control at any time.
Azure SQL automatically backs up the production database on a rolling basis, with 7 days of point-in-time restore available at all times. This is a managed Azure capability, not a manual or ad-hoc process — backups happen continuously without anyone needing to trigger them.
If the application tier fails or needs to be rebuilt, it's redeployed from source control to Azure App Service — there's no server-specific state to lose, so recovery is a redeploy, not a restoration. If the database is lost, corrupted, or needs to be rolled back (for example, after a bad data change), it's restored from Azure SQL's point-in-time backups to a new database, then the application is pointed at it.
This is a backup-and-restore strategy appropriate to the service's current size and stage — it is not a multi-region failover setup, and there's no formal recovery-time objective (RTO) or recovery-point objective (RPO) committed to today beyond "restorable to within the last 7 days." As MeetingMinder grows, this page will be updated to reflect any changes to that strategy.
Questions about this process? Reach out — we're happy to walk through specifics.