Privacy Policy

Information We Collect

If you have an account, we collect only what we need to run the monitoring service you signed up for. (There are two things we collect from visitors who have no account, through the certificate checker and the site scan on our home page. They get their own section below.)

• Account details. Your email address, your name if you provide one, and a hashed version of your password. We never store your password in plain text. If you ask to change your email address, we keep the request until it is confirmed, cancelled or lapses: the new address, your current one, the IP address the request came from, and the codes in the confirm and cancel links we email, which we store only as hashes. Once a change is confirmed, we keep your previous address for up to 72 hours, with the code in the link we send it to undo the change, also stored only as a hash. While we keep it, the address stays reserved for your account: no one can sign up with it and no other account can move to it, so nobody can stop the undo by taking the address first.
• Sign-in and device information. For each device signed in to your account we record the IP address, your browser’s user agent and a device label derived from it (for example “Chrome on macOS”), an approximate city and country, and when the session was last active. This powers the Active Sessions list in your settings so you can see where your account is signed in and sign out a device you do not recognise. The session identifier itself is stored only as a hash.
• Security credentials. If you enable two-factor authentication, we store your TOTP secret encrypted and your single-use backup codes as hashes. If you create API keys, we store only a hash and a short prefix so we can show you which key is which.
• Monitor configuration. The URLs, hostnames, and ports you ask us to monitor, along with the check intervals, regions, timeouts, and alert settings you choose.
• Monitoring results. Uptime logs and performance metrics produced by our probes, including response times, DNS and TLS timings, status codes, error messages, SSL expiry dates, and the incidents derived from them.
• Organization and team data. Your organization name, the members you invite, their roles, and their notification preferences.
• Organization audit log. A record of sign-ins, security changes and email address changes on its members’ accounts, changes to its subscription, and changes to its settings, with who made each one, when, and the IP address and country it came from. It has its own section below.
• Ara and Guided setup. If you set up a monitor, a status page or alerts with Ara, our AI assistant, or with Guided setup, your saved progress and the results of any reachability checks you run. Ara and Guided setup have their own section below, including what Ara sends to Google.
• Billing identifiers. If you subscribe to a paid plan, we store the customer and subscription identifiers issued by Stripe. We never see or store your card number.
• Status page subscribers. If you enable email subscriptions on a public status page, we store the email addresses of the people who subscribe so we can notify them of incidents.

The Certificate Checker and Site Scan (No Account Needed)

Our home page has two tools you can use without an account: a box that checks a domain’s security certificate, and a full site scan that checks a domain across ten areas and gives you a shareable report. You do not need an account for either, so these are the only parts of Pingara that collect something from people who are not customers. Here is exactly what happens. Some points below apply to one tool and say so; the last one, the note of domains we keep indefinitely, applies to both.

• You give us a domain name, and that is all we keep from it. Type a domain, or paste a full web address if that is easier. We throw away everything except the domain before doing anything else. The path, the query string, any sign-in details in the address, and anything else in the link never reach our records.
• The certificate checker never requests a page. From our own servers, not from your browser, we complete the encrypted handshake, read the certificate the site presents, and disconnect. We never request a page, so we do not see or store any content from it.
• The site scan requests your home page and robots.txt, and follows where the site itself redirects. We send a plain GET request to the home page of the domain you name, and to its robots.txt file, both from our own servers. No cookies, no sign-in details, and no custom headers go out with either request, and we never follow a link we find on the page. The scan only ever touches the address you gave us, never anything the page links to. If a site sends its own visitors elsewhere (for example from the bare domain to “www”), we follow that redirect too, up to four times, checking each new address against the same safety rules before we go there. We identify these requests with a name and a link back to this page, so a site owner can always tell it was us.
• We read what we fetch, but we do not keep it. We read up to 512 KB of the home page (less for robots.txt and the registration lookup below) and turn what we find into counts, yes/no answers, and pass/fail results, for example how many images are missing alt text, whether a security header is present, or how a certificate’s expiry compares to today. Two things are the exception: the page’s title, which we keep because the report shows it, capped at 120 characters, and a short supporting note on some results, capped at 200 characters. Neither the page itself, its headers, nor any error message is ever stored.
• Some things we deliberately never store, from either tool: the IP addresses a domain resolves to, response headers as sent, and raw DNS text records. From the site scan’s domain registration lookup, we also never store any registrant name, address, phone number, or email address.
• The registration check asks the domain’s registry, not the domain itself. To show when a domain was registered and when it expires, we ask the public registry responsible for that domain ending, using a lookup called RDAP, the modern replacement for WHOIS. That request tells the registry which domain you asked about. We keep only the dates, the registrar’s name, and a few status flags from the answer, never the registrant contact details described above.
• Your IP address is scrambled before it is stored. We need to recognise repeat requests so neither tool can be abused, but we do not need to know who you are, so we store a one-way fingerprint of the address rather than the address itself. These abuse-prevention records are deleted within 30 minutes of being written.
• If you accept analytics cookies, Google Analytics is told which domain you scanned. When a site scan starts, and when a report page shows a finished result, we send Google Analytics an event with the domain and, for a finished result, its score. Google Analytics links that event to the identifier it keeps for your browser and, if you are signed in to Pingara, to your account. Anyone who opens a shared report link and has accepted analytics cookies sends the same event. If you have not accepted analytics cookies, the event is not sent. The certificate checker on its own sends no such event.
• A site scan report gets its own link, and that link is the only way to see it. The link contains 32 random bytes that we generate, so it cannot be guessed, and we mark the report page so search engines never list it. Anyone who has the link can view the report, so treat it the way you would treat any other link you are willing to share. We keep a report for 24 hours and delete it automatically within 24 hours and 20 minutes of when you started the scan.
• We keep a note of which domains have been checked or scanned, and we keep it indefinitely. This one applies to both tools. Separately from any report, and outliving it, we keep the domain you asked about, how many times its certificate has been checked, how many times it has been scanned, and when it was first and most recently seen by either tool. Any leading “www.” is removed from the domain, so that www.example.com and example.com are recorded as one entry. We do not shorten it any further: if you check shop.example.com, shop.example.com is what we keep. The certificate checker only adds to this note once the site has answered and presented a certificate, so a domain we could not reach, and anything that was never a valid domain name, is not recorded at all. Beyond those counts and timestamps, the only other thing that can go in this note is a contact email address and a short note, and only when someone on our team enters one, in order to contact that domain’s operator about monitoring it. Nothing here is about you or the device you used, so nothing, whether a report, its link or any of the results, can be traced back to the person who ran the check from our own records. Google Analytics is the one exception, described next, and only if you accept analytics cookies. We use the note to understand which kinds of site people are checking, and, when we hold a contact address, sometimes to email it about monitoring the domain. Every outreach email we send carries a one-click link that stops all further contact about that domain, permanently. Deleting a report does not delete this note. If you would rather we did not keep it, email us at support@pingara.io and we will remove it, contact address, note and all.

Our lawful basis for both tools is legitimate interests: running the feature you asked us to run, keeping it from being used to attack other people, understanding what people use these tools for, and letting site operators know we can monitor their site. The last two apply to the note of checked and scanned domains described above, which identifies no person. No cookie is set by either, and both work whether or not you have accepted any.

Please only check domains you own or are allowed to test. See our Terms of Service. If you operate a domain and would rather it could not be checked this way, email us at support@pingara.io and we will exclude it from both the certificate checker and the site scan.

Organization Audit Log

Every organization on Pingara has an audit log. It records who signed in to its members’ accounts, who changed its subscription, and who changed its settings, along with when it happened and the IP address and country it came from. In Settings, only the organization’s owners and admins can see it. It can also be read through our Developer API with an API key that an owner or admin created for reading the audit log, for as long as that person is still an owner or admin, so it reaches whichever tool or person the organization gives that key to. An ordinary API key cannot read it: access to the audit log is a separate permission, chosen when the key is created. Here is what goes in it.

• What we record. Sign-ins and sign-outs, signing a device out, failed attempts to sign in to an existing account (including a wrong two-factor code), password changes and resets (including a reset someone else requests using your email address), requests to change the email address on an account and their confirmation, cancellation or undoing, cancelling the link that would undo one, and turning two-factor authentication on or off or generating new backup codes. A failed sign-in is recorded only when the email address typed is exactly the one on the account, and it is recorded shortly after the attempt rather than at the moment it happens. Plan changes and failed payments on the subscription, and opening the billing portal. Changes to the organization’s name and owner, its members, invitations and roles, its API keys, alert policies and alert channels, and its webhook subscriptions.
• Who did it. The member’s name and email address as they were at the time, so an entry still reads correctly if they later change either or leave. A change made through our Developer API names the member who created the API key it was made with, and the name that key had at the time. Subscription changes that Stripe reports to us name Stripe rather than a person. Changes that Pingara’s staff make to an organization, such as changing a member’s role or who owns it, changing its plan, revoking the API keys of an account we have deactivated, or removing a member’s two-factor authentication at their request (which also records the password reset link it sends), are shown as made by “System”. The log never names the member of staff. When our staff remove a member’s two-factor authentication and that cancels an email address change still waiting, the cancellation is shown as made by “System” too, with its cause saying our staff removed two-factor authentication. API keys revoked because an email address change was undone are also shown as revoked by “System”.
• Where it came from. An IP address and the country it belongs to, which we look up with ipapi.co (see Third-Party Services below). The log records the country only, never the city, and an entry can show an address with no country if the lookup has not been made or did not succeed. For sign-ins, sign-outs, security changes, email address changes, creating or revoking an API key, and changes made through our Developer API, this is the address the request came from. For an email address change, that is the request that asked for it, confirmed it, cancelled it or undid it, so a change confirmed, cancelled or undone from a link we emailed shows the address of whoever opened that link. For most other changes made in the browser, it is the address of the member’s most recently active session, and the log marks it “via session” so it is not mistaken for the exact address. Subscription changes reported by Stripe, and changes shown as made by “System”, carry no IP address.
• What it applied to. The kind of event, the thing it was about (for example a member, an invitation, an API key or an alert policy), and, when a setting changed, its old and new value, such as the organization’s name or a member’s role. When a change of a member’s email address is confirmed, the entry records both the old address and the new one. When a member asks to change it, or the request is cancelled, the entry records the requested address with most of it hidden: only its first character and its domain. A cancellation entry also says what cancelled the request: the cancel link, the member in Settings, a password change or reset, signing out everywhere, an undo, or our staff removing the member’s two-factor authentication. When a confirmed change is undone, the entry records the address the account goes back to, and the address it moves away from with most of it hidden in the same way. An undo also writes a password reset entry for the link it sends, marked as caused by the undo. When a member cancels an undo link, the entry records the address the link would have restored with most of it hidden in the same way.

Sign-ins, security changes and email address changes are about your account rather than about one organization, so we record them in every organization you belong to at the time. If you are a member of more than one organization, the owners and admins of each one can see when and from where your account was signed in to, including sign-ins you made to work in a different organization, and any failed attempts to sign in to it. If you change your email address, each of them can also see the address you used before. If you ask to change it, each of them can see the first character and the domain of the address you asked for, even if the change is never confirmed. Entries already recorded in an organization stay there after you leave it, until they are deleted at 90 days old.

We keep the audit log to protect accounts and the service, and so that an organization’s owners and admins can see who has accessed and changed it and spot a sign-in or a change they do not recognize. Our lawful basis is legitimate interests: ours in keeping accounts secure, and your organization’s in being able to account for what happens in it.

We keep each entry for 90 days, and a daily cleanup then deletes it, so an entry is gone within a day of reaching that age. Deleting an organization deletes its whole audit log. Entries can be copied out through our Developer API, as described above. A copy made that way is held by the organization, not by us, and our 90-day deletion does not reach it.

Ara and Guided Setup

Ara is Pingara’s AI assistant, and uses Google’s Gemini model. It answers questions about Pingara and about your organization’s monitors, incidents and status pages, can suggest help center articles, and can help you set up a monitor, a status page or alerts. Guided setup is a step-by-step form for creating a monitor or a status page, or for setting up alerts, and uses no AI. Ara is not switched on for everyone yet. Where it is, any member of an organization can ask it questions, but a member can set up a monitor, a status page or alerts through it only if their role allows it. You can turn Ara off in Settings, and Guided setup still works.

• What Ara receives. When you send Ara a message, we send it, with the recent messages before it, to Google’s Gemini model through the Gemini API so it can write a reply. Before a message leaves our servers, we cut any web address in it down to its host name, and we replace email addresses, passwords, login headers and anything that looks like a key or token with “[removed]”. This works by spotting the shape of those things, so please do not type anything private into the chat. With your messages we send these facts about your plan and organization: the plan’s name, the check intervals it allows and the one we recommend, how many monitors and status pages your organization has, how many alert policies it has turned on, and the limits on its plan, which monitor types and alert destinations it can use, and how many regions a check runs from. We also send whether your role lets you add monitors, add status pages and set up alerts, whether the turn is for setting up a monitor, a status page or alerts or for general help, and excerpts from our public help center articles. When Ara is helping you set up a monitor and your setup draft has an address in it, we also send the draft’s monitor type, the name and check interval you entered, the result code of its last reachability check, and whether you have already created the monitor. When Ara is helping you set up a status page, we also send the page’s name, the part of its web address you chose, whether it will be public or private, and how many monitors you have picked for it. If you have already created that page, we send only that it was created, in place of those details. When Ara is helping you set up alerts, we also send the name you gave a new alert policy, which of its five alerts (down, degraded, recovery, SSL certificate problems, and pause and resume) you have switched on or off, the kinds of channel you picked, such as email or Slack, and how many monitors you have picked. If the setup updates an alert policy your organization already has, we never send that policy’s name, but the on or off settings we send for its five alerts can be its current ones, as Guided setup shows them. If you have already created that setup, we send only that it was created, in place of those details. Guided setup never passes a channel’s name or its details, such as a webhook address, a routing key or an email address, to Ara. If you paste one into the chat, it gets the same redaction as the rest of your message, so a web address still reaches Google as its host name. Each name goes through the same redaction as your messages. This includes details you entered in Guided setup: Guided setup itself uses no AI and sends nothing to Google, but what you enter there is saved as a draft, and the draft reaches Ara if you use Ara before you finish it. We never send your email address. The address you are setting up a monitor for is shared with the model as its host name only.
• Your organization’s account summary. While your organization allows it, every message you send Ara also carries a summary of your organization’s account, whether you are asking a question or setting up a monitor, a status page or alerts. This lets Ara answer questions about your account. For each monitor it lists, the summary holds its name, the host name it checks (never the full web address, and nothing for an IP address), its type and status. For as many monitors as fit, starting with the one behind an incident you are looking at and up to 3 you name in your message, it also holds their regions, their uptime, Apdex score and p95 response time for the last 7 days, their SLA target and 30-day SLA figure, and any jitter (unsteady response times) or latency spike we measured, with when it happened. Where there is room, each of those monitors that has an SLA target also gets its SLA figure for up to the last 3 complete calendar months, in UTC, each measured against its current target because we keep no record of earlier targets. For each month, that is how many checks ran and how many succeeded, whether the target was met, at risk or breached, and on how many days uptime fell below the target. If the monitor was created during one of those months, the summary gives the day it was created. For incidents still open or started in the last 30 days, it holds when each started, was acknowledged and was resolved (if it has been), its status, a short code for the type of error, and the regions affected. For each status page it lists, it holds the name and whether the page is public or private. In a large account, some monitors, incidents and status pages are left out, and the summary says so. Names get the same redaction as your messages, and we also remove IP addresses (IPv4 and IPv6) from them, including ones written in full-width and other compatibility forms. As with your messages, this works by spotting the shape of those things. The summary never includes your members’ names or email addresses, who acknowledged or worked on an incident, notes or root cause text a member writes on an incident, the error messages recorded with an incident or its checks, a monitor’s request headers or body, status page subscribers, or our internal identifiers.
• The incident you are looking at. When you message Ara from an incident’s page, and the incident belongs to your organization, the summary also includes that incident, however old it is. It adds how long the incident lasted (or has lasted so far), the response time of the check that opened it, how many checks failed in each region while it was open, the types and times of its timeline events, and whether it was a simulated test. A timeline event says what happened, such as an acknowledgement or a note being changed, never what a note says. If the incident has an AI incident report, we also send the report’s summary and up to 3 of its likely causes, with how confident the report was in each and when it was written. A report can describe an error in its own words, so before it leaves our servers we cut any web address in it to its host name and remove paths, query strings, IP addresses, quoted text, email addresses and anything that looks like a key or token. As with your messages, this works by spotting the shape of those things. We never send the report’s evidence, timeline or recommendations.
• Switching off AI access to account data. AI access to your organization’s account data is on unless an owner or admin switches it off, for the whole organization, in Settings, Organization. While it is off, Ara gets no account summary or incident details, we do not write the automatic incident report, and members cannot ask for root cause hints or an AI incident report. The questions Ara suggests are then general ones and never mention your monitors or incidents. An incident resolved while it is off never gets an automatic report later. Ara still answers, and still receives your messages, details of any monitor, status page or alerts you are setting up, and the facts about your plan described above. Each member can also turn Ara off for themselves in Settings.
• Questions Ara suggests. Before you send your first message, Ara offers a few questions you can press to ask. While your organization allows AI access to account data, up to two of them can come from its recent activity: a monitor that is down now, had an incident in the last two days or keeps having incidents, or a suggestion to set up a status page if you have none. A question about a monitor names it and can say roughly when its incident started or what kind of failure keeps happening. We work these out on our servers from your own organization’s monitors, incidents and status pages, show them only in your chat panel and do not keep them. Nothing about them is sent to Google unless you press one. Pressing one sends its words as your own message, just as if you had typed them, with the same redaction as your messages.
• Where the conversation is kept. We do not store or log what you and Ara write. Apart from the copy Google keeps, described under Third-Party Services, the conversation is kept only in your browser, in the tab you are using, and is cleared when you close that tab. We do count how many messages you send, so we can limit use, but not what they say.
• Your setup draft. When you set up a monitor, a status page or alerts, with Ara or with Guided setup, we save your progress so you can pick it up later, on any device. For a monitor, that is the address you are setting up, the monitor type, name and check interval you chose, the step you reached, and the result of the last reachability check. Any login details in the address are removed before it is saved. For a status page, it is the page’s name, the part of its web address you chose, whether it will be public, the monitors you picked and the step you reached. For alerts, it is the name you gave a new policy or which existing policy you chose to update, which of the five alerts are on, the kinds of channel you picked, the monitors you picked and the step you reached. A channel’s name and details are never saved in the draft. If you use Ara while the draft is unfinished, part of it is sent to Google, as described under “What Ara receives” above. A draft lapses 7 days after you last changed it, and a daily cleanup then deletes it. It is also deleted with your account.
• Reachability checks. When you ask whether an address can be reached, our monitoring probes, which run on Amazon Web Services, connect to it from your plan’s regions, as a monitor would. We keep the address, who asked, and each region’s result code, response time and status code for 15 minutes, and a cleanup deletes them within 30 minutes of the check. These checks never count toward your uptime, incidents, alerts or reports. To stop them being misused, we also count your requests against a keyed hash of your IP address (for an IPv6 address, of its network part), never the address itself, and an hourly cleanup deletes each count once it is more than 75 minutes old.
• Your setup checklist. To show your organization what is left to set up, and to measure how long new organizations take to get started, we record when your organization first created a monitor and a status page and first set up alerts with Guided setup, and how each was made: with a form, with Guided setup, with Ara’s help or through our Developer API. Each monitor and status page also records how it was made. We also record when a test alert was first requested, when one was first accepted for delivery, when a member first confirmed in Pingara that one arrived, and whether the organization was created when someone signed up. These records do not say which member did any of it. For each member, we record when they hide the checklist from their dashboard. This is separate from Google Analytics, so we record it whether or not you accept analytics cookies. The record of firsts is kept for as long as your organization exists, even after the monitor or status page it describes is deleted, and is deleted with the organization. A member’s hidden checklist setting is deleted when they leave the organization.
• Analytics. If you accept analytics cookies, Google Analytics also records which setup steps you reach, in Ara or in Guided setup, the result code of a reachability check, the monitor type and check interval you chose, when you create a status page, when you set up alerts, when you turn Ara on or off, and the reason when Ara cannot answer. These events never include the address you are monitoring or your email address.

How We Use Your Information

Your data is used to operate the service, and for nothing else:

• Running the checks you configure and detecting outages and degraded performance.
• Populating your dashboard, charts, uptime and Apdex figures, SLA reports, and incident history.
• Sending the alerts and weekly reports you have opted into, through the channels you configure.
• Showing you where your account is currently signed in, and letting you revoke a device or sign out everywhere.
• Protecting your account when its email address changes. You need your current password to ask for the change, and the new address must confirm it within 24 hours. Meanwhile we email your current address with the new address partly hidden, the IP address the request came from (and its country, when we already know it), and a link to cancel. Changing or resetting your password, or signing out everywhere, also cancels a change that is still waiting. Once the change is confirmed, we tell your previous address that it happened, with the new address partly hidden.
• Letting your previous address undo a change it did not expect. The email we send it has a link that works once, for 72 hours. Using it puts the previous address back as your sign-in email, signs out every device, turns off your password, and sends a link to set a new password to that same previous address. It also revokes every API key your account created after the change was asked for, in every organization. We also tell the address your account moved away from that the change was undone and every device was signed out, with no link in that email. It does not change your two-factor authentication settings. If you made the change yourself, you can cancel the undo link in Settings with your current password. It keeps working for 24 hours after you cancel it, and we email your previous address to say when it will stop, so someone who has taken over your account cannot quietly remove your way back in. Anyone who can read your previous mailbox can use the link. They can then set a password and sign in, unless your account has two-factor authentication turned on, and either way you are signed out and can no longer reset your password yourself. If that is a work address you are moving away from, that can include your former employer.
• Following up a possible account takeover. When an undo link is used, we open a report for Pingara’s staff so they can check what happened. It holds the address the account went back to, the address it moved away from, the IP address the undo came from and its country when we already know it, when the change was asked for and confirmed, which API keys were revoked, and how many devices were signed out, plus whether our staff have resolved it and their note. Only Pingara’s staff can see it. Our lawful basis is legitimate interests: ours in keeping accounts and the service secure.
• Keeping each organization’s audit log, so its owners and admins can see who signed in and who changed what.
• Helping you create a monitor or a status page, or set up alerts, with Ara or Guided setup: saving your progress and, for a monitor, checking that an address can be reached. If you use Ara, also answering your questions about Pingara and, unless your organization has switched off AI access to account data, about its monitors, incidents and status pages and suggesting questions to ask about them, and suggesting help center articles.
• Showing your organization what is left to set up, and measuring, across organizations, how long new ones take to set up and which of our setup tools they use, so we can improve them.
• Managing your account, plan limits, and billing, and answering your support requests.
• Helping you back into your account if you lose your two-factor device. Email our support address, and once our staff have checked it is you, using what we already hold about your account and never a copy of an identity document, they can remove two-factor authentication from it. That also signs out every device, turns off your password, cancels any email address change still waiting, and emails your sign-in address a link to set a new password. In our internal record of the removal, our staff note a ticket reference and the checks they made, never the details you sent them.
• Keeping the service secure, including detecting abuse and enforcing rate limits.
• Finding and fixing errors in our website and app, and finding slow pages.

The law asks us to say which legal reason, called a lawful basis, we rely on for each use:

• Providing the service (contract). Running your checks, your dashboard, reports and incident history, the alerts and weekly reports you choose, your account, sign-in sessions, plan, billing and support, and Guided setup and reachability checks. We need to do these to provide Pingara to you under our Terms of Service.
• Keeping accounts and the service secure (legitimate interests). Protecting your account when its email address changes, the undo link and the account takeover report, support’s help when you lose your two-factor device, rate limits and abuse detection, and the audit log. For the audit log, your organization also has an interest in being able to account for what happens in it.
• Ara and our other AI features (contract and legitimate interests). For the member who uses Ara, or asks for root cause hints or an AI incident report, this is part of the service under our terms. The automatic incident report, the account summary, and the details of anyone else that can appear in what we send, such as a person named in a monitor’s name, rely on legitimate interests: yours and ours in answering questions about your own monitoring and explaining incidents on it. You can turn Ara off, and an owner or admin can switch off AI access to account data.
• Analytics (consent). Google Analytics records your visits only if you accept analytics cookies, and you can change your choice as described under Cookies & Analytics below.
• Fixing errors (legitimate interests). Sending error reports, page timings and page records to Sentry relies on legitimate interests: yours and ours in a website and app that work. It does not depend on your cookie choice and sets no cookies.
• Measuring setup (legitimate interests). Measuring how long new organizations take to set up, and with which tools, relies on legitimate interests: ours in finding out whether our setup tools help new customers, so we can improve them. Showing your organization what is left to set up is part of providing the service.
• The free tools (legitimate interests). The certificate checker and site scan rely on legitimate interests, as described in their section above.

We Never Sell Your Data

We do not sell, rent, or trade your personal information to third parties, and we do not share it with advertisers. The service providers listed below process it strictly on our behalf so that Pingara can function. Your data also reaches people and tools through the organizations you belong to: their owners and admins can see those organizations’ audit logs, as described above, and the alert destinations and other tools an organization connects receive what it sets them up to receive, as described in the last two entries of the list below.

Third-Party Services

Pingara relies on a small number of established providers, and each receives only the data required for its role. The last two entries are different: they are destinations and tools your organization chooses, not our providers, and they receive what your organization sets them up to receive:

• Convex hosts our database and backend, and therefore stores your account, monitor, and monitoring result data.
• Amazon Web Services hosts the Pingara web application and runs the monitoring probes that perform your checks.
• Stripe processes payments and manages subscriptions. Card details are entered on Stripe’s own systems and never pass through ours.
• Resend delivers transactional email such as alerts, verification messages, and weekly reports, and receives the recipient address and message content.
• ipapi.co turns an IP address into an approximate location: a city and country for your Active Sessions list, and a country for your organization’s audit log. We send it an address when you open your Active Sessions list, and when an audit log entry is recorded for an address we have not already looked up, which can happen shortly after a sign-in. We reuse a cached answer wherever we have one, rather than sending the same address again. Lookups made for audit log entries are limited to 20 an hour across the whole service, and if one fails, the audit log does not ask about that address again for a day.
• A domain’s own registry receives the domain name when you run a site scan, so we can look up its public registration record. See The Certificate Checker and Site Scan section above for what we keep from the answer.
• Google (Gemini) powers our AI features. When you ask for root cause hints, we send the model the monitored address and the timing, status and error details of the relevant check. When you ask for an AI incident report, and automatically when our monitoring checks resolve an incident, we send the model the monitored address, the monitor’s name, the incident’s error type and message, the regions that failed, when it started and ended, the response time of the check that opened it, and the timing, status and error details of up to 50 of the checks around it. In all three, the monitored address goes without its query string, port or login details, and any IP address in it or in an error message is replaced with a placeholder. An owner or admin can switch off all three for their organization, as described in the Ara and Guided Setup section above. When you use Ara, our AI assistant, we send it your messages and the other details described in that section, including, unless your organization has switched it off, a summary of your organization’s account. We use Gemini through Google’s paid service. Under Google’s terms for that service, Google processes what we send on our behalf and does not use it to improve its products. Google’s Gemini API usage policies say Google keeps it for up to 55 days to detect misuse of its service and to meet legal requirements.
• Google Analytics measures how our website is used, including which domain a site scan was run on. Its script loads, and it records your visits, only if you accept analytics cookies (see Cookies & Analytics below).
• Sentry receives reports of errors in our website and app, from your browser and from our servers, and timing details for a sample of page loads and requests, so we can find and fix faults. From your browser it also receives a short record each time a page opens. We remove the contents of requests, sign-in cookies and keys, and every part of a web address after the website it belongs to, and we do not attach your account. See Cookies & Analytics below for what your browser sends it.
• Alert destinations you configure, such as Slack, Microsoft Teams, Discord, PagerDuty, or your own webhook endpoint, receive the incident details we send on your behalf.
• Tools your organization connects, such as its own scripts, automation services or AI agents, receive data from your organization’s account. An owner or admin can create a Developer API key, and any tool or person they give it to can read whatever that key allows. A key with write access can also create, change and delete monitors, acknowledge and update incidents, and set up webhook subscriptions. A webhook subscription sends details of the events chosen for it to the address chosen for it. An owner, admin or editor can set one up, and so can anyone holding a key with write access. API keys and webhook subscriptions can both carry monitor and incident details, and the incident details include the name and email address of the member who acknowledged or resolved an incident, as they were when that member did so. An API key created for reading the audit log also reaches the audit log, as described in the Organization Audit Log section above. Your organization chooses these tools, not us, and what a tool does with the data it receives is a matter between your organization and whoever provides that tool.

Cookies & Analytics

We use a session cookie to keep you signed in. This cookie is essential to the service and cannot be turned off while you are logged in. When you change a display setting, we remember your choice in your browser: light or dark mode and the organization you last opened in its local storage (the organization until you log out), and whether the app’s side menu is collapsed in a small cookie that lasts 7 days from your last visit.

Analytics cookies are optional, and Google Analytics does not load until you accept them. Until you press Accept on our cookie banner, no Google Analytics script loads, no analytics cookie is set, and Google Analytics receives nothing from your visit. If you decline, it never loads. If you accept, Google’s analytics script loads and sets two cookies, named _ga and _ga_ followed by an identifier, which Google sets to last two years, and we send it the page views and events described in this policy. A page view gives the address of the page you open, never anything after it that could carry a one-time code. Our other events record when you sign up, sign in, start the demo, read a help center article (which one), create a monitor (with its type and check interval) or a status page, or open the billing portal, besides the site scan and setup events described earlier. Google’s tag also sends events of its own: when a visit starts, when it is your first visit, how long you spend on a page, and when you scroll most of the way down a page, start or submit a form, search our site, download a file or click a link to another website. A file download sends the file’s name, its address and the link’s text, and a click on a link to another website sends that link’s full address and its text. If you are signed in, we also tell it the plan of the organization you have open and your role in it, and attach an internal identifier for your account (never your name or email address), so it can count your visits on different devices as one person’s. When you press a button to upgrade to Pro or to resubscribe, and when that organization moves from Free to Pro while you have Pingara open, we also send it an event that names the Pro plan, with a fixed price and, for a completed upgrade, a random reference, never details of your actual payment. Accepting turns on analytics only: Google’s advertising storage stays turned off either way. We remember your choice in your browser’s local storage, which is not a cookie, so the banner does not ask you again on every visit.

You can change your choice at any time with the Cookie settings button below, or with Cookie settings at the foot of our website’s public pages, such as the home page and the help center. Pressing it withdraws any earlier acceptance straight away: we delete Google Analytics’ _ga cookies from your browser and, if its script is running, reload the page without it. The cookie banner then opens again so you can choose afresh. If you have our website open in other tabs, close or reload them too, so the script stops running there as well. Our cookie banner also appears on the status pages we host for our customers. The choice you make there is stored there separately from the choice you make on our website, so Cookie settings on our website does not change it, and for now you can change it only by clearing that site’s data in your browser. If you accept there, Google’s two analytics cookies are set for pingara.io as a whole, so your browser holds them for our main website too. Cookie settings on our website removes those cookies, but not the choice stored on the status page, so visiting that status page again can set them again.

We also use Sentry to find and fix errors. Sentry is built into our own website code, so it runs on every page whatever you choose on the cookie banner, but it sets no cookies and stores nothing in your browser. From your browser it sends Sentry three things: a report when something goes wrong, saying what failed and where in our code, with your browser, operating system, language and time zone and a short trail of what happened just before, such as clicks and page changes; timing details for about 1 in 10 page loads and page changes on our live site, so we can find slow pages; and, each time you open a page or move to another, a short record with a new random identifier, the time, your browser and whether an error happened, so we can see how often pages fail. We cut every web address in these down to the address of the website it belongs to, such as ours or the site that linked you to us, and page names to their first part, so the rest of a link, which can carry a one-time code, is not sent. We do not attach your account, name or email address, and we do not record your screen. An error message can include text from what you were doing, such as a monitor’s name. Because these go straight from your browser to Sentry, Sentry can see the IP address they come from.

When you mark a knowledge base article helpful or unhelpful, we record that rating against a random identifier stored in your browser, so the same article is not counted twice. It is not linked to your account, and you do not need one to read the knowledge base.

If you use Ara, our AI assistant, the conversation is kept in your browser’s session storage for that tab, which is not a cookie, so it survives a page reload. It is cleared when you close the tab.

Who We Are and Where Your Data Is Processed

Pingara is run by BitSleuth Ltd trading as Pingara, a company registered in England and Wales (company number 16733578), with its registered office at 65 Harland Avenue, Sidcup, England, DA15 7NY. We are the data controller for the personal data described in this policy. That means we decide how and why it is used, and we are responsible for looking after it.

While the company is based in the UK, the infrastructure that runs Pingara is hosted in the United States. Our web application and database run with providers there, so your account details, monitor configuration and check results are stored and processed in the US.

Our monitoring probes run in several regions so we can check your services from more than one place: currently US East (N. Virginia), US West (Oregon), Europe (Ireland) and Asia Pacific (Singapore). Checks run from the regions you choose, and their results are sent back to our US-hosted infrastructure.

When your data moves from the UK to the US or elsewhere, we protect it with the safeguards UK data protection law requires. Depending on the provider, that is either the UK-US data bridge (for providers certified under it) or the UK International Data Transfer Addendum to the standard contractual clauses. If you’d like to know which applies to a particular provider, email us at support@pingara.io.

Data Retention

Individual check results are high-volume time-series data and are kept for a short period. We aggregate them into hourly and daily rollups, which we retain longer so that your uptime history and SLA reporting remain available. Account, organization, and monitor configuration data is kept for as long as your account is active.

How far back your monitoring history goes depends on your plan. See our pricing page for the current retention windows. If your organization moves to the Free plan, history beyond the shorter Free plan window is no longer available, as described in our Terms of Service.

Our cache of resolved IP locations is purged automatically after 30 days. The abuse-prevention records behind the certificate checker and the site scan are purged within 30 minutes of being written, and a site scan report itself, meaning its results and the link they live at, is deleted automatically within 24 hours and 20 minutes of when the scan started. The certificate checker produces no report at all: it returns its answer to you and stores nothing about the result. One thing outlives both tools: the note of which domain was checked or scanned, how many times by each, and when we first and last saw it, described in the section on those two tools above. We keep that indefinitely, and it holds nothing that identifies you.

Signing a device out takes effect immediately, and we keep the record of that session for 14 days afterwards before deleting it. That delay is deliberate rather than housekeeping: the record is what tells us the session was revoked, so removing it too early would let an already-signed-out device be accepted again. Sessions you never sign out of are removed after 14 days of inactivity, and everything goes when your account is deleted.

A request to change your email address is deleted as soon as it is confirmed or cancelled, when you make a new request in its place, or when you change or reset your password or sign out everywhere. One that is never confirmed lapses 24 hours after it was made, and an hourly cleanup then deletes it. It is also deleted with your account. When a new request replaces an earlier one, we keep the code from the earlier request’s cancel link, as a hash only, until that request would have lapsed, so the link still cancels. The record behind an undo link, which holds your previous address and keeps it reserved for your account, is deleted once the link has been used to undo the change. Otherwise it lapses 72 hours after the change was confirmed, or 24 hours after you cancel it if that is sooner, and the same hourly cleanup then deletes it. Both are also deleted with your account.

A report about a used undo link stays until our staff have resolved it, and a daily cleanup deletes it one year after it was resolved. It is not deleted with your account, for the reason given under Your Rights & Data Deletion below.

Whether you start it with Ara or with Guided setup, a setup draft lapses 7 days after you last changed it, and a daily cleanup then deletes it. It is also deleted with your account. The results of a reachability check are kept for 15 minutes and deleted within 30 minutes of the check. We do not keep your conversations with Ara at all.

Organization audit log entries are kept for 90 days and deleted automatically within a day after that, or sooner if the organization is deleted. They are not deleted with your account, for the reason given under Your Rights & Data Deletion below.

Security

All communication with Pingara is encrypted in transit using HTTPS. Passwords are stored only as salted hashes, and credentials for the integrations you configure are handled as secrets. If you enable two-factor authentication, your TOTP secret is encrypted at rest and your backup codes are stored as hashes, so neither can be read back out of our database.

Pingara is multi-tenant by design: every monitor, incident, and report belongs to a single organization, and access is checked against your membership on every request. No security measure is perfect, but we treat the protection of your data as a core part of building the product.

Children’s Privacy

Pingara is not intended for children. As set out in our Terms of Service, you must be at least 13 years old to use the service, and we do not knowingly collect information from anyone younger. If you believe a child has given us their information, contact us and we will remove it.

Your Rights & Data Deletion

You may contact us at any time to request a copy of the data we hold about you, to correct it, or to have it deleted. You can also remove your data yourself, in this order:

• Delete your organization. This is what removes your monitoring data. Monitors, check results, rollups, incidents, alert rules, status page entries, and the organization’s audit log are all deleted with it. Only an owner can do this, the organization must be on the Free plan, and any other members must be removed first.
• Delete your account. Once you no longer belong to any organization, deleting your account removes your user record along with your saved sessions, any outstanding password reset or email verification tokens, any email address change still waiting to be confirmed, any link that could still undo one, and your setup drafts. Account deletion is blocked while you are still a member of an organization. Audit log entries that name you in organizations you used to belong to are not removed with your account: they stay visible to those organizations’ owners and admins until they are deleted at 90 days old. A record of who changed an organization is only useful if the person who made a change cannot erase it. A report about a used undo link is not removed with your account either: it is our record of a possible takeover of the account, and deleting the account may be one of the things whoever took it over did. It is deleted one year after our staff resolve it. If you would like us to consider removing any of these sooner, email us and we will look at your request.

If you are in the UK and unhappy with how we have handled your data, you have the right to complain to the Information Commissioner’s Office at ico.org.uk. We would appreciate the chance to put things right first, so please contact us before you do.

To make a request, or to ask anything about this policy, email us at support@pingara.io. If you subscribed to a public status page, every notification we send includes an unsubscribe link.

Changes to This Policy

This policy may change as the service evolves. When we make material changes, we will update the date above. Your continued use of Pingara after a change means you accept the updated policy. See also our Terms of Service.

Contact Us

Questions about this policy, or about the data we hold on you? Email us at support@pingara.io and we will get back to you.