This register lists the third parties ("sub-processors") that process personal data on our behalf in connection with the Stedwatch website and the my.stedwatch.com customer portal. The optional mobile push channel is listed too, but it is not yet in service and its providers process nothing today (see the scope notes). The controller is tomventures GmbH (Switzerland, CHE-284.308.806, registered in Windisch AG); contact hello@stedwatch.com; provider details are in the Impressum. It complements the Privacy Policy, which describes what we hold and why.
Local by design. The Stedwatch desktop monitor runs on your own machine and sends its monitoring data to no one. A paid Pro key (and the trial) activates online per machine and is re-checked on a repeating schedule for as long as the Software runs - every 15 minutes until the key is accepted, then every 12 hours - sending the key, a one-way machine hash (pseudonymous, not anonymous: it cannot be reversed back to your machine, but it is stored beside your account) and the version running on that machine, and verifying locally in between; that activation data is held by us on our own EU-hosted server, not passed to any sub-processor below. The free tier performs no activation. Apart from that activation check, there are two optional messages the Software can send to a server we run, and both are off unless you switch them on. The first is the Outside Watch heartbeat: 83 bytes (a registration number, one state byte, a counter and a signature, no monitoring data), once a minute or every ten minutes on Free (
exe-poc/OutsideBeat.cs PeriodSecFor, 600 s, and ping/src/budget.mjs NOMINAL_PERIOD_SEC, free: 600; it was five minutes until 2026-09-08), to ping.stedwatch.com, off unless you switch it on and described field by field in the Privacy Policy, section 5a. The second is the app route (Privacy Policy, section 5b), off unless you switch it on and available on Beta, Trial or Pro: your server dials out to relay.stedwatch.com and your own phone reads through that line. What travels is sealed on your machine before it leaves, under a key made there for each phone you pair that we never hold, so relaying and reading are different acts; the relay stores nothing at all. Those records are held by us on our own server, not by a sub-processor below. The sub-processors below relate to sales, the customer account, hosting for Outside Watch and the app route, and - engaged by nothing today - the optional push channel; never to your monitoring or trading data.Honesty note. The exact identity of some providers, and a signed data-processing agreement (DPA) with each processor, are still being finalised. Where a data-processing agreement is not yet in place we say so honestly (to be executed) rather than presenting it as settled. This register is updated whenever a sub-processor is added, removed, or changed.
1. Sub-processor register
| Sub-processor | Role / service | Data it receives | Location | Transfer basis | DPA status |
|---|---|---|---|---|---|
| Lemon Squeezy | Payments / merchant of record: sells the licence, takes payment, handles VAT and other applicable taxes, and issues invoices and receipts. Card and payment data are held by Lemon Squeezy and its payment processor, never by us. | Customer name, billing address, card / payment data, email, purchase and invoice data; a reference linking the account to the Lemon Squeezy order. | USA | EU/CH to US: SCCs plus EU-US DPF / Swiss-US DPF as applicable. | To be executed |
| Hetzner Online GmbH | Hosting: the dedicated server where the portal runs and where the MariaDB database and all personal data at rest live. | Everything the portal stores at rest (account email, encrypted licence keys, order reference, marketing-list entries), plus standard server access logs containing IP address and user-agent. For customers who switch Outside Watch on, also the heartbeat records the receiver stores on the same server in its own database: per machine the registration (random id, the machine's public key, account id, plan, interval), its current state (last heartbeat instant and counter, last state byte including a queued Windows restart, alarm deadline, gap counters), an hourly uptime history, alarm episodes and delivery attempts, an audit trail; per account the sealed Telegram chat id (AES-256-GCM, key outside the database) and the hashes of registration and connection codes. No IP address is stored in that database. | Germany (EU/EEA) | None needed (data stays within the EU/EEA). | To be executed |
| RunCloud | Server management panel: provisions and manages the server on the control plane. It administers the host rather than storing the portal's personal data. | Server and deployment configuration, plus administrative access to the host. | Control plane (region to confirm). | Confirm (SCCs if outside the EU/EEA). | To be executed |
| METANET AG (SMTP relay) | Transactional email delivery: transmits the six-digit passwordless sign-in code, the sign-in notice, and the licence-key emails (Pro / beta / trial). Until a separate bulk provider is configured, the same account also carries the bulk rail - expiry reminders, beta feedback, the lead double-opt-in confirmation and the guide delivery; see the marketing-email row below. | Recipient email address; the six-digit sign-in code; the licence key in transit; the sign-in notice's timestamp and IP address; the body of the emails listed. Plus the SMTP transport metadata Metanet keeps in its mail logs: envelope sender and recipient, our sending IP, timestamps. | Switzerland - METANET AG, Josefstrasse 218, 8005 Zurich | None needed for the Swiss processing (revFADP). For EU/EEA personal data under the GDPR: the European Commission's adequacy decision for Switzerland, so no SCCs are required. | To be executed |
| Marketing email provider (name to confirm) | Newsletter delivery: sends the double-opt-in marketing emails to subscribers who have consented, and handles unsubscribe links. | Subscriber email address, consent record (IP, user-agent, timestamp, source), and unsubscribe status. | Confirm (depends on chosen provider). | Confirm (SCCs / DPF / adequacy, depending on provider and location). | To be executed |
Alert transit is user-directed. When you choose to receive alerts, the transport you pick carries them to your own device and to nobody else. Telegram carries more than alerts, and more than text: the full alert text, the daily summary, the weekly summary whose message is a rendered chart image of your server's CPU, memory and disk activity, and the bot's answers to the commands you type (
/status, /report, /mute, /unmute, /help) - for which the Software holds a long-poll connection open to Telegram for as long as it runs, in weeks with no alert too. You supply the bot token and the chat, so all of it goes from your machine into your chat. Mobile push via Expo, Apple's APNs and Google's FCM is not yet in service: the app has not been released, no device can be paired, and the Software contacts no push provider, so those three receive nothing today. When the app ships it will carry less than Telegram: your device push token, a fixed title, and one of four fixed severity lines. No server name, no terminal or EA name, no measurement, no account number, no description of the fault; the app fetches the detail from the read-only API on your own machine. You select and enable these channels, so they are a user-directed carve-out, not a Stedwatch sub-processor for stored personal data. No account or database records live with them; nothing is engaged unless you turn the channel on. One exception: the optional Outside Watch alarm (Privacy Policy, section 5a) is sent from our server through our Telegram bot to the chat you connected, because it is about your server having gone quiet. What Telegram receives from us is the chat id and the message text: a label or "this server", the instants with their zone and the waiting time we applied; never a metric, hostname or account number. Whether that makes Telegram a register entry of its own is to confirm with counsel.2. Scope notes
- We store, for the customer account, the following: the user's email, sign-in session data (including IP address and browser user-agent, for security), the licence key(s) (encrypted at rest, AES-256-GCM), a reference linking the account to the Lemon Squeezy order, and, for a paid or trial key, the online-activation records described in the next point. No password (passwordless: a single-use 6-digit code by email), no card data.
- A paid or trial key activates online per machine and re-checks every 12 hours thereafter (every 15 minutes until the key is accepted): we hold, per activation, a one-way machine hash (pseudonymous, not anonymous: it cannot be reversed back to your machine, but it is stored beside your account), the activation IP address and user-agent, and first-seen and last-seen timestamps, for seat enforcement (free-tier keys perform no activation). This activation data sits on our own Hetzner server in Germany (EU/EEA) and is not shared with any sub-processor; a seat is auto-released after 30 days idle, and all of it is deleted when you delete your account. We never receive your monitoring or trading data through activation.
- The database and all personal data at rest sit on a Hetzner server in Germany, inside the EU/EEA, so no third-country transfer applies to that data.
- Card and payment data live with Lemon Squeezy as merchant of record and its payment processor, never with us. That transfer to the United States relies on the safeguards shown in the register (SCCs plus the EU-US / Swiss-US Data Privacy Framework as applicable).
- Alert transit is chosen and enabled by you, and is a user-directed carve-out rather than a Stedwatch sub-processor for stored data. Telegram carries the alerts, the daily and weekly summaries (the weekly one as a chart image) and the bot's answers to your commands; mobile push via Expo / APNs / FCM is not yet in service and engages nobody today. The Outside Watch alarm is the exception described above: sent by our bot, on your instruction, to the chat you connected.
- Outside Watch (opt-in, all tiers): the heartbeat records listed in the Hetzner row are held by us, on the same server as the portal, in a separate database with its own least-privilege database users; the receiver stores no IP address (held in memory for rate limiting only and redacted from its log). Retention: the hourly history, alarms and audit trail for 90 days, the registration and alarm destination for the life of the registration; switching a machine off deletes its records at once through a signed withdrawal, and deleting your account erases all of it in the same transaction. Encrypted nightly backups are kept for two weeks, so a deleted record can survive in a backup for up to 16 days. Email and mobile push exist in the receiver's schema but are not deliverable in this build, so no other provider is engaged for Outside Watch.
- The app route (opt-in, Beta / Trial / Pro): your server dials out to
relay.stedwatch.com, a systemd unit on the same server as the portal, and your own phone reads the readings it asks for through that line. They are sealed on your machine (AES-256-GCM, one key per paired phone, made there and never held by us), so the relay cannot read what it carries. It stores nothing - no database, no file, no key - so there is no record of yours on it, nothing to retain, and nothing for account deletion to erase. What it observes while a line is open: that an installation is connected, when it connects and disconnects, how much it forwards, and the source IP at the connection layer; its own log names the installation by a 20-character fingerprint of its public key and carries no IP. Journal retention on the host is to confirm. No sub-processor other than the host is engaged. Privacy Policy, section 5b. - Fonts are self-hosted; there is no Google Fonts or other font CDN embed, so no font provider appears here.
3. Changes to this register
We keep this register current and update it whenever a sub-processor is added, removed, or replaced. Material changes are reflected here with a new "last updated" date. For questions about this register or our processors, contact hello@stedwatch.com.