Privacy
Privacy notice for MetriBeacon Last updated: 13 October 2026
1. Controller and contact
Questions about data protection and the exercise of your rights can be submitted through our contact form at https://metribeacon.com/contact.
2. Website visits and account creation
The web server processes the IP address, time, requested address, HTTP status and technical browser information to deliver the website and detect errors and abuse. For human accounts, we process the email address, short-lived sign-in and security challenges, protected verification values for one-time codes and link tokens, sessions, account settings and security events. Sign-in is passwordless; password verification values are not processed for sign-in. Machine registration can begin without an email address. For this, we process the public Ed25519 recovery key, hashed management credentials, registration origin and time, short-lived security challenges and hashed IP or IPv6 /64 prefixes to limit abuse. After confirmed activation of a new account, we store the accepted terms and acknowledged privacy notice by their document versions, server-side request and confirmation timestamps and registration method. No additional IP addresses or browser identifiers are stored for this record. The document versions are archived immutably. An optional email address is initially stored as pending and marked as verified only after successful confirmation. Service and alert emails contain the data necessary for their purpose.
Sign-in with Google or GitHub is optional; email sign-in remains available. When a user selects a provider, their browser is redirected to it. For verification, MetriBeacon receives the persistent provider identifier and information about the email address and its verification. Only openid and email permissions are requested from Google, and user:email from GitHub. Provider registration can create a new account for a suitable verified address. Existing accounts link a provider only after explicit selection and a fresh MetriBeacon email code. MetriBeacon stores the provider identifier to associate it with the account; changes to a provider email address or GitHub username do not automatically change the MetriBeacon email address. Provider access tokens are processed only during server-side verification and are not stored permanently. Sensitive account actions continue to require MetriBeacon email codes.
For browser session management, MetriBeacon stores the browser family, operating system and device category, together with the start, expiry and last authenticated access of each session. On successful sign-in, it also stores the full client IP address, User-Agent and, where available, an approximate location with city, region and country. These sign-in details remain unchanged for the session and are visible only to administrators for access review and troubleshooting; they are not used for authentication. Location is determined on the MetriBeacon server using locally stored DB-IP data, without sending the client IP to a location provider. VPNs and mobile networks can affect accuracy; older sessions without these details remain unknown. Automatic requests and live updates count as access; this timestamp is updated at most once a minute without extending the session. IP histories and device fingerprints are not stored. All session information is removed on revocation, cleanup after expiry, or account deletion. You can end individual sessions or all other sessions while keeping the current session.
Passkeys are an optional sign-in method for already activated accounts. We store the credential identifier, public verification key, transport and backup information, signature counter, chosen name, creation and last-use time, and a stable account identifier. Your device or passkey provider stores the private key and may show your account email as its label. MetriBeacon does not receive private keys or biometric data. Enrollment requires a fresh email confirmation; passkeys do not create new accounts or replace the first email confirmation. One-time browser-bound WebAuthn challenges expire after five minutes and are cleaned up after one day. Public verification data remains until the passkey or account is deleted. Email sign-in remains available if a device is lost.
For administrative access review and troubleshooting, successful accesses with device keys, machine credentials and OAuth connections record a client-supplied installation identifier and User-Agent (program version and platform where reported), the authorized monitor association, and first and last access times. These details are visible only to administrators and are not used for authentication or as proof of a physical device. Up to 20 client entries are stored per key or connection, timestamps update at most once a minute, and entries are deleted after 30 days without access or on deletion of the key, connection or account. Client and agent installations store a random identifier in a private local file; hardware identifiers are not collected. These accesses do not create browser sessions.
3. Monitoring data and product functions
User-created workspaces, monitors, groups, series, labels and API key verification values, together with submitted numeric values, states, text messages, job/workflow runs, timestamps and heartbeats, are processed for display, alerts, history and export. For explicitly configured HTTP monitors, the service processes the target address, bounded check results, response time and certificate data; optional headers are stored encrypted and used only for checks of the original target origin. HTTP response bodies are not stored historically. Complete job logs are not collected automatically. Separately enabled central log sources process the submitted messages, structured attributes and optional trace identifiers for search, live display, export and alerts. Known secret fields and configured masking rules are applied before durable storage; unmasked originals are not retained. Agent log sources require local approval and mask before encrypted local buffering. Rule and delivery states, incidents, usage and quota data support the service. For repeatable management requests, we store the client-selected idempotency key, a hash of the request content and the first successful result per account. Users determine what their devices send; text messages may contain personal data. Anyone submitting data relating to other people must ensure an appropriate legal basis and, where necessary, arrange a data processing agreement.
4. Purposes and legal bases
Accounts, data intake, history, exports, sign-in and service emails and explicitly configured alerts provide the requested service (Article 6(1)(b) GDPR). Records of acceptance of the terms and provision of the privacy notice support performance and documentation of the agreement (Article 6(1)(b) GDPR) and the legitimate interest in being able to establish how it was concluded (Article 6(1)(f) GDPR). Access protection, abuse prevention, fault diagnosis and operational security are based on the legitimate interest in a secure and reliable service (Article 6(1)(f) GDPR). Where statutory obligations apply, Article 6(1)(c) GDPR applies. Acknowledging this privacy notice is not blanket consent to data processing. Responsibility for user-uploaded data depends on the specific use; any required data processing agreement is concluded separately.
5. Cookies and local browser data
For sign-in, we use a secure session cookie readable only by the server and a cookie protecting against unauthorized changes (CSRF); both last at most seven days. A secure cookie binds a sign-in request to the browser for at most ten minutes. The browser tab session retains the email address and metadata of a pending sign-in request, including confirmed document versions, to resume the process. Codes and magic-link tokens are not stored there. Metadata is removed on completion or an explicit change of address and loses validity when the request expires. The selected sidebar state is stored in a cookie for seven days. Your chosen light/dark setting remains locally in the browser until changed or deleted. These storage functions serve the requested sign-in, security or display settings. Information about audience measurement with PureStats is in section 13.
Your monitor view selections are stored locally in this browser for each signed-in account, workspace and monitor. They include tabs, filters, searches, time selections, expanded categories and hidden chart lines, but no measurements or access credentials. Relative time windows are refreshed when you return; fixed historical ranges remain unchanged and Live resumes. At most 100 views and 512 KiB are retained per account, with older entries removed first. These preferences remain after sign-out and browser restart until removed through browser settings or account deletion in this browser. They are not synchronized to other browsers. If browser storage is unavailable, selections are kept only in memory for the current application session.
When you save a named table view, its name, filters, search and sorting are also stored locally in this browser, separately for each signed-in account, workspace, page and table. Measurements, access credentials and pagination cursors are not stored. This provides the reuse of your list view that you explicitly selected. Up to ten named views are retained per table and up to 100 tables with a combined 256 KiB per account; older entries are removed when needed. Saved views are applied only when you select them. You can rename or delete them. They remain after sign-out and browser restart until you delete them, clear browser data or delete your account in this browser. They are not synchronized to other browsers. If browser storage is unavailable, they remain only in bounded memory for the current application session.
The selected language is stored in the secure __Host-mb_language cookie for at most one year. The website reads this cookie to apply your selection; unlike the session cookie, it is also readable by the website's JavaScript. The “Automatic” setting uses browser language preferences. For signed-in accounts, we also store the selected interface and notification language in account settings until changed or the account is deleted. A queued notification retains the language selected when it was queued, including retries.
An additional secure cookie readable only by the server (__Host-mb_oauth) binds an optionally initiated Google or GitHub sign-in to the browser for at most ten minutes. Short-lived OAuth attempts contain hashed state, nonce and browser-binding values and an encrypted PKCE verifier. These data protect against unauthorized sign-in and replay. Callback codes, state and provider tokens are not stored in MetriBeacon API or web server access logs.
Your favorites and recently opened monitors, series and status pages are synchronized with your account. We store only resource references and timestamps, not measurements, credentials or full navigation URLs. Up to 50 favorites remain until removed or account deletion. Up to 20 recently opened resources expire after 30 days. Resources you can no longer access are hidden, and deleted resources are removed. This information provides the personal navigation you request.
When you save a named report selection, its name, report definition, filters, timezone and relative or fixed period are synchronized with your account for the selected workspace. Up to 50 selections are stored per person and workspace until you delete them or the account or workspace is deleted. They are personal preferences, including in shared workspaces. Saving does not store report results or extend result retention. Access to sources is checked again when used.
6. Recipients and storage locations
The web application, database and outbound email run on the server operated for MetriBeacon. Archive files are transferred through encrypted SFTP to a Hetzner Storage Box. According to the operator, hosting and archive storage exclusively use Hetzner infrastructure. Email recipients and their mail providers receive the respective message. For the optional Telegram product bot, only after voluntary linking of a private chat and activation of the channel are the chat identifier, linking messages and user-selected alert and test messages transmitted to Telegram. Without a linked chat, no alerts are delivered through Telegram. Users voluntarily contacting the operator through https://metribeacon.com/contact leave MetriBeacon; Telegram processes data according to its own rules. Email is also available for this contact. A user-selected public HTTP target receives the MetriBeacon checker's IP address, HTTP request and any explicitly configured headers during a check. For explicitly authorized OAuth access, the selected client receives a short-lived token limited to MetriBeacon and the displayed permissions and can retrieve the authorized account data. Publicly registered OAuth clients store their name, redirect addresses and a hashed network prefix.
When Google or GitHub sign-in is voluntarily selected, the provider receives, in particular, MetriBeacon's client identifier, redirect address, requested permissions, state and PKCE challenge; Google also receives a nonce. When the provider page is visited, the provider also processes the user's IP address and browser information. Google and GitHub can thereby recognize that the user intends to sign in to MetriBeacon or link access. The respective provider's privacy notice applies to its processing: Google's at https://policies.google.com/privacy and GitHub's at https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement. Merely visiting the MetriBeacon sign-in page does not start a provider flow.
Optional ChatGPT and Claude Code connections use the same explicitly authorized MCP interface. MetriBeacon stores the account, registered client, resource, selected permissions, creation and last-use time, expiry and, for CLI-approved machine connections, the originating credential and workspace binding. Access and refresh tokens are stored only as hashes. The selected AI service receives authorized tool results, which may include user-submitted monitoring data; its own privacy rules apply. The optional embedded monitoring interface receives results through the MCP Apps host bridge, without access tokens or private API credentials. The catalog integration uses a separate OAuth resource. Its tools exclude API key issuance, secret HTTP headers, notification credentials, webhook secrets, subscribers and domain verification; these remain on the MetriBeacon website. Merely visiting MetriBeacon does not connect an AI service.
7. Retention
Active sessions last at most seven days; email sign-in requests with magic link and code last ten minutes, and security challenges for sensitive actions last five minutes. Invitation links and email change links last at most 24 hours; links to add an email address to machine accounts last at most 30 minutes. Confirmation records containing the account, document versions, timestamps and registration method remain until account deletion and are removed then. Archived published legal documents do not contain user confirmation records and remain available as a public document archive. Expired authentication data is regularly removed. Machine challenges expire after five minutes and are regularly cleaned up one hour after expiry; registration limit events after two days. OAuth authorization requests and codes expire after five minutes, MCP/OAuth access tokens after 15 minutes, and their expired database rows are regularly cleaned up one day after expiry. Unused public OAuth client registrations are removed after 90 days without use and without associated authorization or token rows. Public recovery keys and hashed management credentials remain until revocation or account deletion; encrypted HTTP headers until monitor or account removal. Original measurements, complete text messages and detailed run events are available for at most seven days; compact run and availability aggregates follow the aggregate periods below. Original values generally remain local for only six hours, then in the verified archive. Minute aggregates are retained for 30 days, quarter-hour aggregates for 365 days and hourly aggregates for 1,095 days. Archive files may remain for one additional hour before deletion for boundary buckets and active jobs. Deduplication and eviction records are cleaned up after eight days; short-lived intake counters after seven days and creation events after 31 days. Incident summaries, including recorded values and short message excerpts, remain until the account is deleted. Delivery records and completed mail and test jobs are removed after 90 days; deliveries linked to an open incident remain until resolution and for at most another 90 days. Each HTTP monitor keeps at most its 20 most recent diagnostic checks until replaced by newer checks or the account is deleted. These contain timings, address family and safe failure categories, without target addresses, header values or response content. Completed account deletion jobs are removed after 90 days and recorded operator actions after 365 days. Archive query and export jobs expire after one day. Central logs are retained for seven days by default, configurable per source from one to 30 days. Expiry, source deletion and retention reductions immediately block access; physical cleanup follows within 24 hours. Central-log query and export copies expire after at most 15 minutes or earlier with the source data. Log intake receipts expire after 31 days, volume and collection-coverage records after 31 days, and source audit metadata after 90 days. Account data, configuration, latest known values and records of repeatable management requests remain until account deletion. Web server logs rotate weekly with at most five additional archives; mail and system logs rotate weekly with four additional archives. Contact emails remain in the mailbox until deleted after the matter is resolved or further retention is needed for legal evidence.
Google and GitHub sign-in attempts last at most ten minutes and are regularly cleaned up no later than one day after expiry. Provider links remain until explicitly removed or the account is deleted. Confirmed removal of a link ends all MetriBeacon browser sessions. Email sign-in remains available.
New OAuth connections expire after at most 30 days or seven days without use. Access tokens expire after 15 minutes; refresh tokens rotate after each use, and consumed hashes are retained until the connection expires to detect reuse. Connection rows and refresh hashes are removed no later than one day after absolute expiry, or with account deletion. A revoked connection stops access immediately. Ten-minute machine coupling requests store only hashed browser binding and coupling code, together with OAuth request parameters and the approved account, credential, workspace and scopes; expired requests are removed after one day. Secure HttpOnly cookies __Host-mb_mcp and __Host-mb_mcp_csrf bind these requests to their original browser for ten minutes. The separately enabled reviewer login uses a ten-minute __Host-mb_review CSRF cookie, hashed login secret and regular sessions for an isolated synthetic account. Its secret is not included in public plugin packages.
8. Account deletion
Confirmed account deletion blocks access immediately. Subsequent cleanup removes database data, local cache and spool files and associated remote archive files. It runs asynchronously; if remote storage fails, the job remains open and resumes after restoration. A completed deletion job is retained for operational tracking for another 90 days.
9. Rights and complaints
Under the GDPR, data subjects may request access, rectification, erasure, restriction and portability and object to processing based on legitimate interests. Where processing is based on consent, it may be withdrawn for the future. Send requests to https://metribeacon.com/contact. You have the right to complain to a data protection supervisory authority, in particular the Berlin Commissioner for Data Protection and Freedom of Information.
10. Automated decisions
MetriBeacon automatically evaluates user-configured alert rules. It does not make decisions about people that have legal or similarly significant effects.
11. Contact form
When you contact us, we process your optional name, email address, subject and message to handle and respond to your request. Contractual enquiries support pre-contractual or contractual measures (Article 6(1)(b) GDPR); other enquiries are processed based on our legitimate interest in handling incoming requests (Article 6(1)(f) GDPR). No separate consent is required for this. The message is handed to the contact mailbox through our local mail server. We do not send an automatic confirmation email or additionally store request contents in the application database or application logs. To limit abuse, we store short-lived hashed network identifiers and attempt counters; these are removed no later than one day after the start of their last counting window. Retention of contact emails in the mailbox follows section 7.
12. Language preference
The Secure, SameSite language preference cookie __Host-mb_language stores your selection (auto, en or de) for up to one year. It contains no tracking identifier. Signed-in users can also save their interface and notification language with their account. The cookie supports the language selection you explicitly request and is not used for advertising or analytics.
13. Audience measurement with PureStats
We use the external PureStats analytics script (https://purestats.io) on public pages and in the member area to measure visits and website usage. The tracker sends the page URL, page title, referring page, timestamps, and browser and screen information to PureStats. PureStats also receives the IP address and technical browser information when the script loads and analytics requests are sent. Sign-in pages and pages for confirming invitations, email addresses and notification destinations, as well as recovery and agent connection, are excluded from event collection. Public status page subscription management with a secret link token does not load the analytics script. The tracker may cache its configuration in local browser storage for five minutes. Further information about processing by PureStats is available at https://purestats.io/privacy.
14. Internal product statistics
MetriBeacon records selected deliberate product actions and technical outcomes of setup, sign-in, monitoring, integrations and notifications. Examples include opening a dashboard or history, confirmed changes and completed reports. These statistics help improve usability and reliability. App usage, automated monitoring and administrative actions are analysed separately; explicitly marked test accounts remain identifiable. Records contain account-level daily counts, bounded feature and error identifiers, and dates of first setup milestones. There is no general page, click or session recording. Codes, access keys, message content, IP histories and measurement content are excluded. These statistics introduce no additional external analytics service or tracking cookies and are accessible only in the admin area. Daily statistics remain available for up to 1,095 UTC days. Complete rolling 30-day calculations require at most 29 additional days of account-level activity data. First setup milestones remain until account deletion. Account deletion removes individual statistics. Completed totals without an account association and anonymous download counts remain as aggregate statistics. Audience measurement with PureStats continues under section 13.