Skip to content

Trust

Vulnerability disclosure policy

If you find a security problem in RealUptime, we want to hear about it. This page says what is in scope, how to report, what we commit to in response, and what protection good-faith researchers have. There is no paid bounty program today.

Effective August 23, 2026

How to report

Email security@realuptime.io with the subject “RealUptime security report.” Include the affected URL or feature, reproduction steps, the impact you believe it has, and any supporting request or response details. Do not include secrets you do not need to share. The same contact is published in machine-readable form at /.well-known/security.txt (RFC 9116).

The security.txt file is not PGP-signed: RealUptime does not currently operate a published key, and an unverifiable signature would be worse than none. The file is served over HTTPS from the canonical host, which is the integrity guarantee it relies on.

Scope

In scope:

  • realuptime.io and the subdomains RealUptime operates, including the web application, the public status pages, the REST API, and the MCP server.
  • The monitor agent and the GitHub Action that RealUptime publishes.
  • Email RealUptime sends (alerts, receipts, sign-in, status-page subscriptions).

Out of scope:

  • Third-party systems, including the sub-processors listed on /security (Fly.io, Supabase, Stripe, Resend). Report those to the vendor.
  • Customer-operated status-page custom domains and the targets customers monitor. Those are the customer's systems, not ours.
  • Denial-of-service, volumetric testing, spam, social engineering of staff or customers, and physical attacks.
  • Findings with no security impact: missing best-practice headers with no demonstrated exploit, version disclosure, clickjacking on pages with no state-changing action, and automated-scanner output without a working proof of concept.

Rules for testing

  • Use your own account and your own data. A free account is enough for most research.
  • Do not access, modify, or delete data that is not yours. If you reach another person's information, stop, do not retain it, and report it immediately.
  • Do not degrade the service for other users. Keep request rates to what a real user would do.
  • Take only what is needed to demonstrate the issue, then stop.

Response commitment

  • We acknowledge a report within 3 business days.
  • We triage it (confirm, ask for detail, or decline with a reason) within 7 business days.
  • Fix targets by severity, counted from triage: critical (account takeover, cross-customer data access, remote code execution) 7 days; high 30 days; medium 90 days; low on the normal release cycle.
  • We tell you when the fix ships.

These are targets, not a contractual SLA. RealUptime is a small team; if a fix will miss a target we will say so and say why.

Coordinated disclosure

Please give us the chance to fix a problem before publishing it. After the fix ships, or 90 days after triage if we have not shipped one, you are free to publish. We will credit you by name or handle if you want credit; we do not require silence.

There is no paid bug bounty program today. We are not going to pretend otherwise. If that changes it will be announced here and in security.txt.

Safe harbor

Research conducted in good faith, within this scope and these rules, is authorized. RealUptime will not pursue legal action against, and will not refer to law enforcement, a researcher who follows this policy, including under computer-misuse and anti-circumvention laws to the extent we are able to waive them. If a third party brings action against you for research that followed this policy, we will say so on request.

This does not authorize testing of anyone else's systems, and it does not cover research that violates the rules above. When in doubt, ask at security@realuptime.io first.