Vulnerability Disclosure Policy

Last updated: May 2026

Why this policy exists

Rootly is the AI-native platform for on-call and incident management. We help engineering teams resolve incidents faster, improve system resilience, and run smoother on-call operations, with a production AI copilot that automates root cause analysis, surfaces patterns, and drives continuous improvement. Engineering teams at some of the most demanding companies in the world run Rootly when downtime isn't an option. That means security and reliability aren't afterthoughts. They're foundational to everything we ship.

When someone finds a security issue in Rootly, we want a clear, low-friction path to report it, and a predictable, accountable response on our end.

This policy covers any vulnerability you're considering reporting in a Rootly product or property. See Scope at a glance below for what's in and out of scope.

We don't run a paid bug bounty program, but we take researcher contributions seriously. For in-scope reports, we'll credit you publicly once a fix ships.

How to report

Email security@rootly.com. PGP key available on request.

A useful report includes four things:

  • Where — the URL, host, endpoint, or product surface.
  • What — the vulnerability class (e.g., SSRF, IDOR, auth bypass).
  • How — minimal, non-destructive steps to reproduce, plus a benign proof of concept.
  • Impact — one sentence on what an attacker could realistically do.

The clearer the reproduction steps, the faster we can open an incident on our end and ship a fix.

What to expect from us

We treat inbound security reports the same way we treat any customer-facing incident: triaged, owned, and tracked end-to-end.

  • Real vulnerabilities acknowledged within 5 business days.
  • Triage and severity assessment within 10 business days, with a named owner on the Rootly Security team.
  • Ongoing updates as the fix progresses. To keep the team focused on remediation, please check in no more than once every 14 days.
  • Notification when the issue is resolved, with an opportunity for you to validate the fix.

Priority follows the same logic we use for any production incident: impact, severity, and exploit complexity.

Ground rules

Please do:

  • Stay within the law. Use your own test accounts wherever possible.
  • Use the smallest proof of concept that demonstrates the issue, don't exploit it.
  • Respect customer data. If you incidentally access it, stop immediately, report it, and securely delete it within 30 days of resolution (or sooner if legally required).
  • Keep details between you and security@rootly.com.

Please don't:

  • Run high-intensity scanners, fuzzers, or load tests against production systems.
  • Attempt denial of service, resource exhaustion, or anything that could page our on-call team.
  • Modify, delete, or exfiltrate data belonging to Rootly or our customers.
  • Social engineer, phish, or physically target Rootly staff, vendors, or offices.
  • Submit purely informational findings — missing security headers, TLS cipher preferences, SPF/DMARC nits, version disclosure, or clickjacking on unauthenticated pages — unless you can demonstrate real, exploitable impact.
  • Demand payment in exchange for disclosure.

Safe harbor

If you make a good-faith effort to follow this policy, Rootly will not pursue or support legal action against you for your research. We'll work with you, not against you.

This policy doesn't override applicable law or any obligations Rootly has to its customers and partners. If something is unclear, ask us before you test it.

Scope at a glance

In scope

  • rootly.com and its production subdomains, including api.rootly.com, slack.rootly.com, and mobile-api.rootly.com
  • Rootly web app, API, mobile apps (Android + iOS), Slack and Teams apps, and MCP server

Out of scope

  • Third-party services we integrate with — report those directly to the vendor
  • Staff social accounts and personal devices
  • Findings that require already-compromised credentials, rooted devices, or physical access