Privacy Policy

App: Outageloop (Jira Cloud, Atlassian Forge, with an external monitoring backend)
Provider: MernPearl Technology Private Limited (CIN U62099RJ2024PTC097952)
Last updated: 1 October 2026

1. Scope

This policy describes how the Outageloop app ("the App") handles data when it is installed on your Atlassian Jira Cloud site. It covers only the App. It does not cover Atlassian's own handling of your Jira data, which is governed by Atlassian's privacy policy and your agreement with Atlassian.

The App has two parts:

• The Jira app, built on Atlassian Forge. It runs on Atlassian's infrastructure and keeps your configuration in Forge hosted storage.
• The Outageloop backend, operated by MernPearl Technology Private Limited ("MernPearl", "we") on a server in Oracle Cloud Infrastructure, Mumbai region (India). It checks the status pages of the third-party services you choose to monitor and sends status changes back to your Jira site.

The backend holds no personal data (§3). The only personal data the App stores at all is held in Forge hosted storage, inside the Atlassian platform (§2.1).

2. What the App stores in Atlassian Forge

The Jira app stores the following in Forge hosted storage (storage:app — Forge Key-Value Store and Forge Custom Entities), inside the Atlassian platform:

2.1 The only personal data

The only personal data the App persists is an Atlassian account ID: the account ID of the person who attached a dependency to a project, stored in the addedBy field of the project-dependency mapping, in Forge hosted storage. It is never sent to the backend.

The App does not store names, email addresses, avatars, IP addresses, Jira issue content, issue keys, comments, attachments, or any free-text you enter in Jira.

An account ID may additionally appear transiently in Atlassian platform application logs — for example, when the App records that a permission check was denied. Those are Forge platform logs, retained and managed by Atlassian, and are not exported anywhere by the App.

2.2 Permissions the App requests

The App requests three Atlassian scopes: storage:app, read:permission:jira, and read:jira-work.

None of these permit the App to write to, modify, or delete any of your Jira data. The two Jira scopes are read-only: they let the App check whether the current user may view or administer a project, and list the projects a user can see. storage:app permits the App to write only to its own Forge storage.

3. What the Outageloop backend stores

The backend runs on a virtual server in Oracle Cloud Infrastructure (OCI), region ap-mumbai-1 (Mumbai, India), in Docker containers with a PostgreSQL database, a Redis cache and a RabbitMQ queue on the same server. It stores:

Tenant key. Your installation is identified to the backend by a key derived with HMAC-SHA256 from the Atlassian installation identifier and a secret salt held only on the server. The backend does not store your Atlassian site URL, site name, cloud ID or installation ID in readable form.

No user identity. Each request from the Jira app to the backend carries a token signed by Atlassian (the Forge Invocation Token). The backend verifies it and uses only the installation identifier inside it to derive the tenant key. It does not store or log any user identity from that token, and it receives no account IDs, names, email addresses, project names, issue keys or Jira content.

Encryption. Traffic to the backend is encrypted in transit with TLS. Callback secrets are encrypted by the application with AES-GCM; the key is held only in the server's protected configuration. Oracle Cloud encrypts the server's storage volumes at rest by default. The database, cache and queue accept no connections from outside the server.

Logs. The backend's application logs contain operational events only. Verified on 2026-10-01, they contain no IP addresses, no tenant keys and no callback URLs. The web server in front of the backend keeps no access log for it.

4. Data flows outside the Atlassian platform

This section is a specific disclosure, not a generic third-party clause. Please read it.

There are exactly four flows, and no others:

4.1 Jira app → Outageloop backend

The Jira app calls the backend over Forge Remote (HTTPS) to register your installation, to tell it which catalog services, regions and components to watch, to read status history, and to remove your installation on uninstall. The data sent is listed in §3: the web-trigger URL, the callback secret, opaque source identifiers and catalog selections. No personal data and no Jira content is sent.

4.2 Backend → third-party status pages

On a schedule, the backend sends an outbound GET request to the published status pages and status APIs of the services in its catalog (for example status.stripe.com or www.githubstatus.com). Each service is checked once for all customers, not once per customer.

These requests transmit no customer data. They carry no request body, no credential, no Atlassian site or tenant identifier, no user identity and no Jira content. A status-page operator learns only that a request arrived from the backend server's IP address. The backend reads only the published status.

4.3 Backend → Jira app (status pushes)

When a status you watch changes, the backend sends it to your installation's Forge web trigger, signed with your installation's callback secret. The message contains an opaque source identifier, the region or component, the new status and a sequence number — nothing else.

4.4 Jira app → Slack — only if you connect Slack

If a site administrator connects a Slack workspace, the App posts messages to the Slack channels you configure, using Slack's chat.postMessage API, and calls Slack's auth.test once at connection time to verify the bot token you supplied.

A message contains exactly the Slack channel identifier and one line of text, generated from the display name of the monitored service (for example, "Stripe"), the event type (incident opened, resolved, or severity changed) and the severity (major or minor). It contains no personal data, no account IDs, no Jira issue keys, no project names and no free text of yours. A representative message:

:red_circle: Stripe is DOWN — incident opened (Major severity).

4.5 What does not happen

The App's calls to the Jira REST API stay inside the Atlassian platform. Neither the Jira app nor the backend sends data to any analytics provider, error-reporting service, application-performance-monitoring vendor or advertising network. There are none.

5. Credentials

• Slack bot token — stored in Forge encrypted secret storage, never in ordinary storage, never sent to the backend, and transmitted only to Slack as the authorization header of the calls in §4.4. You can disconnect the workspace at any time from the App's admin settings.
• Callback secret — generated by the Jira app at installation, kept in Forge encrypted secret storage on the Jira side and AES-GCM-encrypted on the backend side. It is used only to sign and verify status pushes (§4.3).

Neither is ever logged or included in error messages.

6. Sub-processors

Slack is a destination you choose and connect yourself, using your own credential; see the Data Processing Addendum §5. Third-party status-page operators receive no customer data (§4.2).

7. Compliance

Data held in Forge hosted storage (§2) inherits Atlassian's SOC 2 and ISO 27001 controls for the Forge platform — physical security, encryption at rest and in transit, tenant isolation, platform network security, logging and backup. See Atlassian's Forge and SOC 2 / ISO 27001 documentation.

That inheritance does not extend to the Outageloop backend (§3). MernPearl is responsible for the backend's controls. MernPearl does not hold its own SOC 2 or ISO 27001 certification for the App and does not claim one.

8. Retention and deletion

8.1 While the App is installed

• In Forge hosted storage, a dependency's configuration, current status, incidents and notification records are kept until you detach that dependency from every project, which deletes them, or until you uninstall.
• On the backend, global status history is deleted after 90 days and delivered status messages after 7 days. Your catalog selections are kept until you change them or uninstall. Your plan's history window (7 days on Free, 30 on Standard) limits how much of that history the App shows you; it does not change what is stored.

8.2 When you uninstall

• Forge hosted storage is cleared automatically by the Atlassian platform: soft-deleted immediately, kept for a platform-managed window during which reinstalling can relink it, then permanently deleted under Atlassian's retention policy. Atlassian does not publish a fixed number of days; see https://developer.atlassian.com/platform/forge/storage-reference/hosted-storage-data-lifecycle/
• The Outageloop backend is told to delete your installation as part of uninstall. This immediately deletes your installation record, callback secret, catalog selections and pending messages from the database and cache. If that call fails, the backend deletes any installation it has not heard from in 90 days automatically, so data cannot be left behind indefinitely.

8.3 Backups

The backend database is backed up nightly. Each backup is kept for 14 days and then deleted. Data deleted from the database at uninstall therefore remains in backups for up to 15 days before the last backup containing it expires. Backups are readable only by the server's administrator account and are used only to restore service after a failure. Callback secrets inside them remain AES-GCM-encrypted.

9. International transfers

The Outageloop backend is located in India. As described in §3, it holds no personal data. To the extent that any information transferred to it is personal data under the law that applies to you, MernPearl relies on the EU Standard Contractual Clauses (and the UK Addendum to them) as set out in the Data Processing Addendum.

10. Your rights

Because the only personal data the App persists is an Atlassian account ID (§2.1):

• Access / portability — the addedBy account ID is held on the project-dependency mapping. No App screen currently displays it, so an access request is served by MernPearl on request.
• Erasure — removing a dependency mapping deletes its addedBy value. Uninstalling the App triggers the deletion described in §8.
• Requests — send any data subject request to privacy@mernpearl.com. Requests about your Jira data generally, rather than this App, should go to Atlassian.

Grievance officer (India, Digital Personal Data Protection Act 2023): dpo@mernpearl.com, or by post to the registered office in §13. We respond within 30 days.

If you are a site administrator acting as a data controller, the Data Processing Addendum (https://outageloop.mernpearl.com/dpa) sets out the processing terms in full.

11. Children

The App is a business tool sold through the Atlassian Marketplace and is not directed at children.

12. Changes to this policy

We will update this policy if the App's data handling changes — in particular if a new destination, storage location or sub-processor is added. We publish every version at https://outageloop.mernpearl.com/privacy with its "last updated" date. For a material change we give at least 30 days' notice before it takes effect, on that page and, where we hold contact details for your site (such as the technical contact of a paid Marketplace licence), by email.

13. Contact

MernPearl Technology Private Limited C/O Sunil Kumar Sharma, Bar Chowk, Pilani, Jhunjhunu, Rajasthan 333031, India Privacy: privacy@mernpearl.com · Data Protection Officer: dpo@mernpearl.com