Privacy Policy

Who We Are

UptimeMonitoring.com is operated by Monitive SRL, Romania, EU. Contact: hello@uptimemonitoring.com.

What We Collect

• Account identity from GitHub OAuth (username, GitHub user ID) — GitHub sign-in requests only the read:user scope, not user:email, so we never request private-email access, and we do not store or use any public email address that may be present in GitHub's profile response — and/or Google OAuth (Google account identifier), whichever you use to sign in.
• If you sign in with Google, Google's authorization response also includes your verified email address. We read it only to parse that response and discard it immediately — we never store it.
• If you sign in with email instead, the email address you use to sign in — a separate thing from an alert-recipient email address below, even if they happen to be the same address.
• An optional notification_email you can add from account settings, separate from your sign-in identity and from any alert-recipient address — used only for product and account outreach (for example, cap-limit notices). The active value is cleared the moment you change, remove it, or delete your account — but that doesn't end storage of the address: every change or removal writes the old and new addresses to an audit event, kept separately for 90 days regardless (see below).
• API request metadata (timestamps, endpoint, response status) for billing and abuse prevention.
• Monitor configuration you provide (URLs, check intervals, alert thresholds).
• Email addresses you optionally supply as alert recipients, separate from any email sign-in address or notification_email.
• API key metadata including creation date and last-used IP.
• Incident records: a 30-day user-visible promise — you can query incidents from the last 30 days through the dashboard, API, or MCP. The underlying rows, and the separate daily uptime-aggregate rows we use to compute uptime bars, physically persist for 95 days after the incident resolves, to support report emails and status pages — an incident that's still open (a monitor that's still down) is kept regardless of age and only starts that 95-day countdown once it resolves. Either way, that longer window isn't something you can query directly. Your account's own evidence buffer (the last 20 check results per monitor) is a separate, much smaller store that we continuously overwrite in place rather than retain on a schedule.
• Webhook, email, Slack, and PagerDuty delivery logs share one table. A delivery still in progress is kept regardless of age. Once a delivery reaches a final state (delivered, failed, superseded, or cancelled), it becomes eligible for deletion in our next daily cleanup once 30 days have passed since that specific outcome — this is an eligibility window, not a guaranteed deletion date, and for an email delivery the retained record is the recipient reference, delivery status, and timestamps, not the message content. This can outlive the recipient itself: deleting a recipient removes only its still-in-progress deliveries, so its completed history (and the now-deleted recipient's id) can still appear in the log until the cleanup runs. Scheduled report emails and their delivery records are a separate store with their own fixed 90-day age cutoff, independent of the window above.
• Account audit events retained for 90 days. If you add, change, or remove your account's optional notification_email, we record an audit event containing the old and new address — any account member or API credential with audit-log read access can see that event until it ages out at the same 90-day cutoff. Deleting your account does not shorten this window: an audit event already recorded keeps aging out on its own 90-day schedule rather than being erased immediately on deletion.
• Server and edge logs (short-lived; used for operations and abuse detection).

What We Do Not Collect

• No tracking cookies on this marketing site beyond session essentials.
• No third-party advertising or analytics pixels.
• No behavioral profiling.

Cookies

This site uses only essential cookies required for authentication and session management. No analytics or advertising cookies are set in the current build.

Third Parties

• Cloudflare — hosting and edge network; processes requests on our behalf.
• Google Fonts — fonts loaded from Google's CDN on marketing and docs pages; your IP and user-agent are sent to Google on page load.
• GitHub — authentication; we receive your GitHub username and GitHub user ID on sign-in. We request only the read:user scope, not user:email — we do not request private-email access, and we do not store or use any public email address that GitHub's profile response may include.
• Google — authentication; we receive your Google account identifier on sign-in, if you choose Google. Google's response also includes your verified email address — we read it only to parse the response and discard it immediately; it is never stored.
• SendGrid — delivers email sign-in links/codes and email alert and confirmation messages on our behalf.
• jsDelivr / Scalar — the API reference page loads the Scalar viewer from jsDelivr's CDN; your IP and user-agent are sent to jsDelivr on that page.
• Stripe — payment processing when paid plans launch; not active yet.

Your Rights (GDPR)

If you are in the EU, you have the following rights:

• Access — request access to and a copy of your personal data.
• Restriction — ask us to restrict processing in certain circumstances.
• Rectification — have inaccuracies corrected.
• Deletion — ask us to delete personal data in certain circumstances.
• Objection — object to further processing in certain circumstances.
• Withdrawal of consent — withdraw consent at any time without affecting prior processing.
• Portability — receive personal data in a structured, commonly used, machine-readable format.

You also have the right to raise a complaint with your data protection authority at any time. We may ask you to verify your identity before responding to a request. To exercise any of these rights, email hello@uptimemonitoring.com. We will respond within 30 days.

Retention

Account data is retained while your account is active and deleted upon request. Incidents carry a 30-day user-visible promise, backed by 95 days of physical storage after resolution (shared with the daily uptime-aggregate rows behind your uptime bars) so we can produce report emails and status-page history — that extra window supports those internal uses, not direct queries from you. An incident that's still open is kept for as long as it's open, regardless of age, and only becomes eligible for that 95-day cleanup once it resolves. Webhook, email, Slack, and PagerDuty delivery logs keep any still-in-progress delivery regardless of age, and make a delivery eligible for our next cleanup sweep once 30 days have passed since it reached a final outcome (delivered, failed, superseded, or cancelled) — an email delivery's retained record is the recipient reference, delivery status, and timestamps, and it can survive, along with a reference to the now-deleted recipient's id, after you delete the recipient that received it, until that sweep runs. Scheduled report emails and their delivery records are a separate store with their own fixed 90-day cutoff. Account audit events, including the old and new address recorded when you change or remove your notification_email, are retained for 90 days regardless of whether you later delete your account — an audit event already recorded ages out on its own 90-day schedule rather than being erased immediately on account deletion. When you delete a monitor, its incidents, evidence buffer, legacy webhook configuration, and delivery records are removed immediately — its daily uptime-aggregate rows are not deleted, only detached from the monitor (they keep contributing to your account's history), and age out on the same 95-day window as incidents. Server logs are short-lived and not tied to individual accounts.

Changes to This Policy

We may update this policy from time to time. The "Last updated" date at the top of this page is authoritative.