Privacy Policy

Dev Bench (developerbench.com) is operated by RedpointRack LLC (“we”). This policy covers two kinds of data: data about you, the person who signs in or writes to us, and data our sensors collect from your application on your behalf. We do not sell data, show ads, or run tracking or analytics scripts on this site.

Data about you

• Your GitHub account. When you sign in we receive your GitHub user id, username, name, avatar and primary verified email address. We do not keep your GitHub access token.
• Contact form. Your name, email, company and message, so we can reply. Your IP address is stored only as a keyed one-way hash, used to stop the form being flooded.
• Newsletter. If you subscribe, we store your email address, where on the site you signed up (the site footer, the homepage or the end of a post) and the date, to send occasional posts about Dev Bench once we start emailing. We don't email subscribers yet; when we do, every email will have an unsubscribe link. As with the contact form, your IP address is stored only as a keyed one-way hash, used to stop the form being flooded. We keep your address until you ask to be removed, or we delete the list. To be removed, write to peter@redpointrack.com.
• Billing. Stripe collects and holds your card or bank details. We store your Stripe customer and subscription identifiers and your plan, never full card or account numbers.
• Cookies. Three, all first-party and none for tracking: a sign-in session cookie (30 days), a short-lived cookie that protects the GitHub sign-in (10 minutes), and your light/dark theme choice.

Data from your application

When you install a Dev Bench SDK, it reports what fails in your application: errors and stack traces, failed and slow requests (method, path, status, timing), the release and environment, and server log lines from around the failure. If you choose to identify users to the SDK (for example by email and account id), those identifiers are attached so an issue can say who was affected. The SDKs redact credentials and known sensitive patterns before anything leaves your application.

For this data you are the controller and we process it on your instructions: to detect, group and triage problems, and to write issues into the GitHub repository you choose. You are responsible for having a lawful basis to send it and for telling your own users. Do not configure the SDKs to send payment card numbers, health information or other special categories of data.

Chat widget conversations

If you turn on the chat widget, the users you admit to it (only users your own server signs in for the widget, never anonymous visitors) can write to it. We keep each conversation's transcript: the messages the user types and the replies, with the email address and account id your server signed for that user (and their role, if you send one). Messages are stored after the same redaction of credentials and known sensitive patterns, so what we keep and what the AI model sees is the redacted text. To answer, the widget uses what our sensors recorded for that user and the help pages you list, which we fetch and index.

When a user asks for help from a person, we send the transcript, their identity and what our sensors saw for them to the support email address or Slack webhook you set, and nowhere else. A handoff by email is sent through Postmark (listed below), with the user's email address as its Reply-To so your support team answers them directly. As with the rest of your application's data, you are the controller of these transcripts: tell your users that the chat is recorded and that it can be passed to your support team.

Triage uses an AI model (see Anthropic below). It receives the error report and related log lines for the problem being triaged; for the chat widget, it receives the conversation and the context needed to answer it. We do not use your data to train models, and our model provider does not train on it under its commercial terms.

Who processes data for us

If you connect Slack, notifications and chat handoffs go to the Slack webhook you provide.

How long we keep it

We keep account data and data from your application for as long as your account is open, so that regressions can be recognised and issues kept up to date. Chat widget transcripts are kept for as long as your account is open too, and are deleted with the rest of your tenant's data. When your account is cancelled or closed, we delete your tenant's data within 30 days, except records we must keep for tax and accounting (invoices and payment records). Deleted data leaves our backups as they expire on their normal cycle. Issues already written to your GitHub repository are yours and stay there. A deletion request for one of your users is completed within the same 30 days, and includes that user's chat conversations.

If we suspend your account, that is not a closure, even though suspending it cancels your subscription: we keep your tenant's data until the account is reinstated or deleted, and the deletion period above doesn't start while it is suspended.

Your choices and rights

• You can ask us for a copy of the data we hold about you, or to correct or delete it.
• If one of your users asks you to delete their data, we can delete everything we hold about that user (by email or account id) on your request.
• Depending on where you live (for example the EU, UK or California) you may have further rights; write to us and we will respond within the time the law requires.

Security

Traffic is encrypted in transit. Sessions are stored only as hashes, integration credentials are encrypted at rest, and each customer's data is isolated from every other's. No system is perfectly secure; if a breach affects your data we will tell you promptly.

Changes and contact

If we change this policy materially we will update the date above and, for customers, tell you by email first. Questions or requests: peter@redpointrack.com, or RedpointRack LLC, PO Box 20104, Cheyenne, WY 82003-7002. See also our Terms of Service.