Privacy Policy
Effective date: 2 October 2026
1. Operator and contact
Resultary is operated by David Finnich. Privacy and support inquiries can be sent to support@getresultary.com.
This policy describes how Resultary processes data through the Jira app, the self-service n8n beta, the public website, billing integrations and support communications. Customers remain responsible for determining whether their own use of Jira and Resultary is lawful and appropriately configured.
2. What Resultary does
Resultary for Jira Cloud is a Forge application that receives a protected automation run signal and verifies whether configured Jira business evidence exists. When a persistent failure is confirmed, Resultary can create and update a Jira incident, manage reminders/escalation and optionally send operational notifications to configured Slack or Microsoft Teams endpoints.
Resultary for n8n is currently a self-service beta. Customers may start a trial through the Resultary checkout flow, receive a scoped integration key after billing confirmation, send workflow-run identifiers to the Resultary API and view independently verified outcome status. The beta may use a separately authorized read-only destination connector to verify an expected result. No contractual 24/7 monitoring or uptime commitment is included unless separately agreed.
3. Data categories processed
- monitor names, expected frequency, criticality, owner/backup-owner information and other monitor configuration;
- Jira project, issue, status, field, changelog, query and result information required for configured verification;
- Jira account identifiers used for incident assignment or escalation;
- timestamps, health state, incident/recovery history, audit information and operational metrics;
- administrator-provided business-impact values and currency;
- optional Slack or Microsoft Teams / Microsoft Power Platform webhook configuration;
- for n8n beta customers: scoped integration identifier, workflow/run identifiers, timestamps, verification state, incident/recovery history, and billing/subscription identifiers and status received from Paddle;
- for approved n8n proof destinations: destination configuration needed to perform the agreed independent check and encrypted server-side destination credentials where required;
- support-message content and sender contact details when someone contacts Resultary directly;
- technical web-request information that may be processed by the website hosting provider.
Resultary is not designed for passwords, payment-card data, health records or other highly sensitive information. Customers should not place unnecessary sensitive information in monitor names, queries, runbooks, impact descriptions or external notification channels.
4. Purposes of processing
- provide and secure the Resultary service;
- monitor configured automation run signals;
- verify configured Jira business outcomes;
- detect, create, manage and recover incidents;
- send configured operational notifications;
- provide reliability, recovery and business-impact metrics;
- respond to support, privacy and security inquiries;
- protect the service against abuse and investigate technical problems.
5. Storage, locations and data residency
Core Jira-edition application data is stored using Atlassian Forge-hosted storage for the installed Jira site. Forge-hosted persistent storage follows supported Atlassian data-residency behavior. Atlassian may update supported locations and residency capabilities over time.
The self-service n8n beta uses a separate Resultary-hosted API and PostgreSQL database for scoped integration keys, run identifiers, verification state, billing entitlement status and related beta operational data. Current beta hosting uses Render and Neon infrastructure in the configuration selected by Resultary. n8n beta data does not use Atlassian Forge storage.
Current Atlassian Forge data-residency information ↗
If an administrator enables Slack or Microsoft Teams notifications, selected alert information is sent to the configured third-party endpoint and is then processed according to that provider and the customer’s configuration.
6. Service providers and recipients
- Atlassian provides Jira Cloud and the Forge platform used to run and store core app data.
- Slack or Microsoft Teams / Microsoft Power Platform receive operational notification content only when the customer enables and configures that integration.
- Render hosts the current n8n beta API.
- Neon provides PostgreSQL storage for the current n8n beta.
- Paddle provides checkout, subscription billing and related payment processing for the n8n beta. Paddle processes checkout contact, billing and payment-method information under its own privacy terms; Resultary does not receive or store full payment-card details.
- GitHub Pages hosts the public Resultary website and may process technical request information under GitHub’s own terms.
- Infomaniak provides the Resultary support-email infrastructure and may process email-routing and mailbox information for messages sent to Resultary.
7. Credentials and secrets
Protected Jira heartbeat credentials and supported notification webhook URLs use Forge secret storage. Customers should treat heartbeat URLs and webhook credentials as secrets and should not send them in ordinary support messages.
n8n beta integration API keys and independent proof-destination credentials must also be treated as secrets. Resultary is designed so the destination-read credential is kept server-side and is not placed in an n8n workflow. Do not send Resultary API keys, temporary setup tokens or destination credentials in ordinary support messages or screenshots.
8. Personal data and Atlassian account references
Resultary may store Jira account identifiers where an administrator configures incident assignment or escalation. The app uses Atlassian Forge personal-data reporting mechanisms so relevant account references can be updated or cleared when Atlassian reports account-status changes.
9. Retention and deletion
Monitor configuration remains until changed or deleted by an authorized administrator, subject to Forge and Atlassian platform lifecycle behavior. Security and audit information uses bounded retention where implemented by the application. Associated Jira incident tickets are Jira records and are not automatically deleted when a Resultary monitor is removed because customers may require those Jira records for their own history or audit purposes.
Support emails may be retained as reasonably necessary to resolve requests, document security/privacy matters and maintain business records. Support and business records are retained only as reasonably necessary for service, legal, security and administrative purposes.
10. Website analytics and cookies
The Resultary public website does not intentionally deploy advertising trackers or product-analytics cookies at this stage. The hosting provider may process ordinary web-server request information as part of operating the hosting service.
11. Your choices and rights
Depending on applicable law, individuals may have rights to request access, correction, deletion, restriction or other handling of their personal data. Requests relating to Resultary-controlled support or business-contact data can be sent to support@getresultary.com. Requests relating to data controlled by a customer’s Jira organization may need to be directed to that organization.
12. International processing
Because Resultary can be installed by customers in multiple regions and can integrate with customer-selected third-party services, data may be processed in more than one country. Forge-hosted app data follows Atlassian’s applicable data-residency configuration where supported; external notification and support providers follow their own customer/provider arrangements and transfer safeguards.
13. Changes
This policy may be updated as Resultary evolves or legal requirements change. The effective date will be updated for material revisions.