Legal, Privacy & Compliance

1. Acceptable Use & Monitoring Targets

You may only create custom monitors for websites, servers, or endpoints that you own or have explicit authorization to monitor. Probing unauthorized systems, conducting denial-of-service (DoS) simulations, or triggering excessive high-frequency polling is strictly prohibited.

2. Bot-Hosting OAuth & API Monitoring

Connecting your Bot-Hosting account grants read-only permission to query your server deployment metadata and current state. You agree to only connect accounts and claim server ports that you rightfully own or co-manage. API monitors evaluate states via the official Bot-Hosting API and are subject to upstream API availability and rate limits.

3. User Submissions, Requests, Appeals & Confidentiality Disclaimer

When submitting outage reports, service feedback, API access requests, ban or report appeals, or monitor and webhook limit increase requests, you agree to provide truthful, accurate, and relevant information. Submitting false reports, fraudulent requests, spamming forms, or attempting to mislead staff regarding service status or ownership will result in immediate denial, revocation of privileges, or a permanent ban.

Submission at Your Own Risk: All user submissions, including outage reports, feedback, API access applications, appeal statements, and limit increase justifications, are stored on our systems, are accessible to and reviewed by staff members and administrators, and are submitted strictly at your own risk. Do NOT include confidential, sensitive, proprietary, or personally identifiable information (such as passwords, secret tokens, private API keys, payment details, credentials, or personal contact info) in any report, appeal, API application, or limit increase request. We accept no responsibility or liability for any sensitive or confidential information you choose to disclose.

4. Service Availability, Detection & “As-Is” Disclaimer

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, UPTIME DATA, INCIDENT REPORTS, WEBHOOK NOTIFICATIONS, AND API TELEMETRY ARE DELIVERED ON A STRICTLY “AS-IS” AND “AS-AVAILABLE” BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR ACCURACY. WHILE WE STRIVE FOR CONTINUOUS ACCURACY, WE DO NOT GUARANTEE 100% UNINTERRUPTED DELIVERY OF EXTERNAL WEBHOOK ALERTS OR REAL-TIME METRICS. WE MAY PROVIDE ROOT-CAUSE SUMMARIES OR POST-INCIDENT REPORTS AT OUR DISCRETION; THEY ARE INFORMATIONAL ONLY, MAY BE REVISED AS INFORMATION BECOMES AVAILABLE, AND ARE NOT GUARANTEED FOR EVERY INTERRUPTION, DEGRADATION, OR INCIDENT.

• Alert & Webhook Delivery: Status alerts (webhooks, Discord notifications, etc.) may not always be sent for every status change. Not all status types will trigger webhook notifications. Delivery depends on upstream service availability, configured thresholds, and internal rate limits.
• Detection Limitations: Various automated methods are used to detect service status, including HTTP probes, TCP checks, ICMP pings, API polling, and component condition evaluations. However, partial degradation, intermittent issues, and some failure modes may not be automatically detected by these checks. Automated monitoring is not a substitute for comprehensive observability.
• User Report-Based Status: Users may submit reports on any monitor to indicate perceived issues. All submitted reports are subject to a character limit, are made at your own risk, and are visible to all staff members at any time, do not include confidential, sensitive, or personally identifiable information in your reports. When a monitor accumulates a sufficient number of reports exceeding its per-monitor threshold, an alert is automatically sent to staff so they can investigate and verify the reported issue. Report-driven status changes reflect community perception and may not always correspond to a verified technical state. Status reverts automatically when reports expire or fall below the threshold. ALL REPORTS ARE CLEARED WEEKLY AUTOMATICALLY, admins can clear reports for any or all monitors at their discretion.

5. Account Termination & Access Revocation

Creating, using, or coordinating multiple accounts to get around per-account limits or restrictions is prohibited. This includes getting extra personal monitors, webhooks, or API keys through additional accounts. We reserve the right to restrict, suspend, or terminate access for accounts that violate these terms, bypass security controls, abuse API limits, or disrupt system operations.

Age Requirement (15+)

You must be at least 15 years old, or the higher minimum age of digital consent required in your country or jurisdiction, to access or use this service, submit reports, or configure custom monitors. By using this service, you represent that you meet this minimum age requirement.

6. Bot-Hosting Service and Separate Subdomain

The Status Tracker is part of the Bot-Hosting service. Its software is developed and maintained as a separate project and runs on its own subdomain and technical infrastructure. This technical separation does not make it a separate service operator. The parent Bot-Hosting legal portal identifies the service operator and provides the parent service terms. Login sessions, cookie preferences, and browser storage do not carry over between the two domains. You must log in and set cookie preferences separately on each site.

7. Limitation of Liability & Exclusion of Damages

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL BOT-HOSTING STATUS, ITS OWNERS, OPERATORS, STAFF, CONTRIBUTORS, OR INFRASTRUCTURE PROVIDERS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING, WITHOUT LIMITATION, LOSS OF PROFITS, LOST REVENUE, LOST BUSINESS OPPORTUNITIES, CUSTOMER CHURN, DATA CORRUPTION OR LOSS, SERVICE INTERRUPTION, OR DOWNTIME COSTS, ARISING OUT OF OR IN CONNECTION WITH YOUR ACCESS TO, USE OF, OR INABILITY TO USE THIS SERVICE, AUTOMATED STATUS CHECKS, WEBHOOK NOTIFICATIONS, LATENCY HISTORY, OR TELEMETRY DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS STATUS TRACKER IS A FREE OPERATIONAL VISIBILITY TOOL AND PROVIDES NO FINANCIAL GUARANTEE.

8. Modifications to Service & Terms

We may change or discontinue features and update these Terms. Revisions and their effective dates are posted on this page. We do not guarantee individual notice. For API Usage Terms updates, we may attempt to notify accounts with an active API key or personal monitor by Discord DM, but delivery is not guaranteed.

Updates: We publish revisions and their effective dates on this page. Please check this page to keep up to date with the current Terms, Privacy Notice, and API Usage Terms. Continued use after an updated Terms of Service takes effect will be treated as acceptance where applicable law allows. The Privacy Notice explains how information is handled; it does not replace any consent choice the law requires. If you do not agree to updated Terms, stop using the service. API Terms apply to API keys and personal-monitor features. We may attempt to send a Discord DM to accounts with an active API key or personal monitor when API Usage Terms change. DMs may not be delivered because of Discord privacy or authorization settings, rate limits, outages, blocks, or other delivery issues. Do not rely on a DM as your only source of updates. By requesting and using an API key, you agree to the current API Usage Terms where applicable law allows. When we issue your first API key, we record the current version as acknowledged. After a later version takes effect, your first valid API-key request records that version as acknowledged, and the key remains usable.

Information We Collect

• Discord Identity: When you log in via Discord OAuth, we receive your Discord User ID, username, display name, avatar hash, and an authentication access token. This token is used strictly to verify identity and periodically refresh active avatars.
• Bot-Hosting OAuth & Deployments: If you connect your Bot-Hosting account, we store your OAuth access/refresh tokens, deployment IDs, server names, assigned nodes, ports, and runtime status. Tokens are used exclusively to fetch deployment lists and power API-based state monitoring.
• Monitors & Webhooks: URLs, ports, check intervals, monitor types (HTTP probe or API cloud check), and webhook destinations (Discord, Slack, Generic) that you explicitly configure.
• Reports, Requests & Appeals: Issue descriptions, affected service selections, application statements, appeal explanations, and limit increase justifications submitted through our forms (all submissions are voluntary, accessible to staff, made at your own risk, and must never include confidential credentials or secrets).
• Security & Session Data: Encrypted session identifiers, IP addresses (used strictly for rate limiting and fraud prevention), and browser user-agent headers.
• Optional Analytics: Google Analytics measures aggregate traffic and popular pages when enabled in Cookie Preferences or by the regional default described below. When disabled, the tag is not loaded, analytics storage is denied, and accessible Google Analytics cookies are cleared.

How We Use Your Data & Third-Party Infrastructure

• Executing periodic health checks on configured services, querying Bot-Hosting API states, and recording latency history.
• Dispatching incident alerts to your configured webhook endpoints.
• Bot-Hosting API: Communicating with api.bot-hosting.net to synchronize deployment states and verify server ownership.
• Cloudflare Reverse Proxy & CDN: Routing traffic through Cloudflare for global edge caching, SSL/TLS encryption, and DDoS mitigation.
• Google Analytics: Measuring aggregate visitor counts and popular monitor views.
• Authenticating administrative operations with 2FA and new device verification checks.
• Mitigating DDoS attacks, abusive scraping, and unauthorized automated API queries.

No Data Selling or Advertising Networks

We never sell, rent, or monetize your personal data. We do not use third-party advertising networks. Data is only communicated to trusted infrastructure providers (e.g. Discord for webhooks/OAuth, Bot-Hosting for deployment telemetry, Cloudflare for network defense, Google Analytics for aggregate metrics when enabled by your choice or regional settings, and Google Translate when you choose to translate the page) as necessary to operate the service.

Legal Basis for Processing

• Performance of the service you request: We process account and configuration data to sign you in and operate the monitors, deployment synchronization, and alerts you choose to use.
• Consent: Optional Analytics and the Google Translate feature are enabled only by your selection where consent is required. You can change these choices in Cookie Preferences at any time. When Analytics is turned off, we send the denied consent signal, stop sending our Analytics events, clear accessible Analytics cookies, and reload without loading the tag; withdrawal does not affect processing that already occurred.
• Legitimate interests: We use security and activity data to protect the service, prevent fraud and abuse, enforce rate limits, investigate incidents, and maintain reliable monitoring, while considering your rights and interests.
• Legal obligations: We may process or preserve information when necessary to comply with applicable law or a binding legal request.

Your Statutory Rights

• Right of Access & Portability: Sign in and visit the account export endpoint to download data currently available to this service. Credentials and access tokens are excluded.
• Right to Rectification: Changing your avatar or username on Discord automatically synchronizes with our platform during session refresh.
• Right to Erasure (“Right to be Forgotten”): When signed in, you can schedule full account deletion from the account data controls on this page. You are signed out immediately, and account-owned data is deleted after 30 days. Sign in with Discord before the deadline to restore your account and cancel deletion. We send deletion status notices by Discord DM when Discord allows delivery. Deleting your Status Tracker account does not revoke its Discord app authorization; you can revoke it separately in Discord User Settings → Authorized Apps. Revoking it may prevent future deletion DMs, including reminders or the completion notice. Shared records, including incident updates you contributed to, are not deleted. Necessary administrator and security logs may remain when you took part in the related activity. A minimal receipt of the request and its outcome is kept for up to 365 days, then deleted.
• Right to complain: You may lodge a complaint with the CNIL in France or with the supervisory authority where you live or work.
• Right to Object & Restrict Processing: You may disconnect Bot-Hosting OAuth or revoke OAuth permissions from your Discord User Settings at any time to immediately halt data synchronization.

API Key Security & Secret Protection

You are solely responsible for keeping your API key confidential. Do not embed keys in public GitHub repositories or client-side JavaScript. Compromised keys should be revoked and regenerated immediately.

Prohibited Uses & Clone Restrictions

• No Commercial Resale: The API is provided for personal and non-commercial integrations unless explicit written permission is granted by Bot-Hosting management.
• No Status Clone Pages: You are not permitted to scrape or reproduce public replica sites whose primary purpose is to mirror this status tracker.
• No Confusing Public Discord Bots: You may not build public bots that clone or impersonate our official Bot-Hosting status bot.
• Rate Limit Compliance: Automated pollers must respect response headers and rate limits. Intentionally spamming endpoints will result in automatic key revocation.

First-Party Cookies and Browser Storage

We use first-party session and security storage such as connect.sid for sign-in and device_id for security and device verification. The one-year device_id cookie is paired with a random browser identifier in local storage. Consent choices are stored in local storage on this browser. Google Analytics uses first-party cookies such as _ga only when analytics is enabled. The optional googtrans cookie remembers a language selected through Google Translate.

Cloudflare Security & DDoS Protection

Our traffic is routed through Cloudflare to protect the status platform against DDoS attacks, automated exploit attempts, and malicious bots. Cloudflare may set technical security cookies (such as __cf_bm or cf_clearance) to distinguish human visitors from automated botnets. These security cookies are required for protection and cannot be disabled here. See Cloudflare’s Privacy Policy.

Optional Cookies, Analytics & Preferences

We use Google Analytics to measure aggregate visitor trends and see which monitor pages are actively viewed so we can keep the infrastructure fast and reliable. When enabled, it may store first-party identifiers such as _ga and _ga_* and receives page-view and basic browser/device signals. We do not use Google advertising or remarketing cookies.

In configured consent-required regions (the EU/EEA, UK, Switzerland, Canada, Brazil, South Korea, Japan, Thailand, Singapore, Australia, New Zealand, South Africa, Turkey, and Israel), first-time visitors can choose I Accept or open Customize to select Analytics and Google Translate preferences individually. Choosing Analytics off keeps its tag unloaded, denies analytics storage, and clears accessible Analytics cookies. Elsewhere, Analytics is enabled by regional default after the country lookup and can be turned off at any time. If we cannot determine your country, we default to required cookies only and show the prompt. The optional Google Translate control and its googtrans language cookie are enabled only when selected. You can open Cookie Preferences from the sidebar or this page at any time. Your choices, settings version, and timestamp are stored in this browser, not as an account-level consent record.

Third-Party Services and Their Policies

These providers operate under their own terms and privacy notices when you use the related feature. Their policies may change.

• Google Analytics, Translate, and Fonts: Google may receive measurement data when Analytics is enabled, page text you choose to translate, or standard connection data when fonts load. Read Google’s Terms, Privacy Policy, cookie information, and Analytics cookie details.
• Discord: Discord processes data when you sign in with Discord OAuth or send alerts to a Discord webhook. Read Discord’s Terms of Service, Privacy Policy, and Developer Terms.
• Cloudflare: Handles network routing, caching, and security checks. See its Privacy Policy and Website Terms.
• Hetzner Online: Hosts the application and database. Read its Privacy Policy.
• Bot-Hosting API: When you link a Bot-Hosting account, deployment information is retrieved through its API. See the Bot-Hosting Terms and Privacy Notice.
• Slack or other webhook destinations: If you configure these destinations, the status and alert details you select are delivered to that provider. Review Slack’s Terms and Privacy Policy, or the policy of your chosen endpoint provider.

Subdomain Isolation & Cross-Domain Boundaries

The Status Tracker is part of the Bot-Hosting service and is developed and maintained as a separate software project. It runs on its own subdomain and technical infrastructure, but that separation does not make it a separate service operator. The parent Bot-Hosting legal portal identifies the service operator and provides the parent service terms. Browser sessions and local preferences remain separate across the two sites:

• Sessions & Login: Authentication on one domain does not grant access on the other. You must log in separately on each site. Discord OAuth sessions are maintained independently.
• Cookies & Preferences: Cookies set by status.bot-hosting.net (including session and analytics cookies), and consent choices stored in browser storage, are scoped to that subdomain and are not readable by bot-hosting.net, and vice versa.
• Cookie Consent: Accepting or declining analytics cookies on the main Bot-Hosting site has no effect on the Status Tracker. You must independently configure your cookie preferences on each site.
• Local Storage & Browser Data: Theme preferences, cached UI states, and any localStorage data are sandboxed per origin by the browser and do not synchronize between the two sites.

Device Verification & MFA

To protect staff accounts, logins from unrecognized devices require multi-factor verification (if setup). Device fingerprinting hashes are stored in encrypted format and used exclusively for security audits.

Data and Retention

• Account-owned data: Profile data, settings, personal monitors, webhooks, reports attributed to your account, requests, credentials, and other data belonging solely to your account are kept while the account is active. When you request deletion, you are signed out and this data is deleted after 30 days unless you sign in with Discord before then, which restores the account and cancels deletion. Shared records (including incident updates you contributed to) remain. Necessary administrator and security logs may remain when you took part in the related activity.
• Custom monitor history: user monitor check history is trimmed to a rolling 48 hours and deleted with the account. Shared public service history remains under the retention behavior described in Monitoring Transparency.
• Webhook destinations and credentials: kept until the user edits or deletes the webhook, or deletes the account. Destination URLs, authorization headers, and signing secrets are masked or excluded from settings responses and exports.
• Cookie choice: stored in this browser until cleared or changed. The recorded date and notice version are not sent to the account database.
• Legal acknowledgments: the version, timestamp, and recorded method for each acknowledged Terms of Service, Privacy Notice, or API Usage Terms are stored on your account and deleted with it. Older records may not include the method. Your cookie choice is separate and stays in this browser.
• Outage reports: account-attributed reports are deleted with the account; shared status history and aggregate results remain under the retention behavior described in Monitoring Transparency.
• Webhook delivery logs: the 10 most recent logs per account are kept for troubleshooting and deleted with the account. Older logs are deleted.
• Admin and security audit logs: administrator activity logs are automatically deleted after 90 days and may remain after account deletion during that period. Other security records may be retained where needed for service security or abuse investigations. Account-specific API access, limit increase, and revocation appeal submissions are deleted with the account unless a necessary portion is retained in an admin or security audit log.
• Deletion request records: a minimal receipt of the request and its outcome is kept for up to 365 days, then deleted.
• Login sessions: expire after up to 30 days without activity and are cleared when the account is deleted.

Providers

• Hetzner Online GmbH: Provides infrastructure for the Status Tracker application and database.
• Discord, Inc. (United States): account ID, username, and avatar for sign-in; configured alert details for Discord webhook delivery.
• Bot-Hosting API: OAuth account link and deployment identifiers, node/port, names, resources, and runtime status. Deployment location can vary by the hosting node; see the parent legal notice for hosting providers and locations.
• Cloudflare, Inc. (United States): request IP and connection metadata for traffic routing, CDN, and network security.
• Google Ireland Ltd. (Ireland / United States): page views and basic browser/device usage signals for Google Analytics when enabled by preference or regional configuration, and page text requested when you use Google Translate.
• User-configured endpoints: status, monitor, incident, and alert details are sent to the Discord, Slack, or generic URL configured by the user. The provider you choose may process that data in its own region and under its own terms.

Some providers may process data outside the EEA, UK, or your country of residence. Where applicable, transfers use an adequacy decision or appropriate safeguards such as the European Commission’s Standard Contractual Clauses. You can ask us which provider handles a particular category of data.

Monitoring Methods

Services are monitored using industry-standard protocols at regular intervals. Depending on the service type, the platform performs:

• HTTP/HTTPS Checks: Automated requests are sent to web endpoints. The platform validates response status codes, response time, and optionally checks for specific keywords in the response body to confirm the service is functioning correctly.
• TCP Port Monitoring: Direct TCP connections are established to verify that specific ports on a host are open and accepting connections.
• Ping (ICMP): ICMP echo requests are used to verify host reachability and measure round-trip network latency.
• Component Monitors: Composite monitors that aggregate the status of multiple related sub-services or infrastructure components into a single parent view, giving an at-a-glance health summary of complex systems.

Monitoring Locations

Checks may be performed from one or more geographic locations depending on the monitor. Not all monitors are checked from multiple locations, and the set of monitoring locations is not guaranteed to be the same across every monitor. Location assignments may change over time without notice as infrastructure is adjusted. When multiple locations are configured, the platform uses the aggregated results to determine overall status and reduce false positives caused by regional network issues. The number of locations and their geographic distribution may vary based on the service type, priority, and available monitoring capacity.

Status States

Each monitored service can be in one of the following states at any time:

• Online: The service is reachable and responding normally within expected parameters.
• Degraded / Issues: The service is reachable but experiencing internal issues, failures, or other which includes being affected by an active incident or the monitor depends on another monitor that is offline/degraded.
• Offline: The service is unreachable or returning error responses consistently.
• Paused: Monitoring for this service has been temporarily suspended by an administrator. No checks are being performed.
• Maintenance: The service is intentionally taken offline or undergoing scheduled work. This state is set manually by staff to indicate planned downtime.
• Issue / Incident: A known problem has been identified and flagged. Staff may attach public notes, updates, or a resolution timeline to the incident.

History & Data Retention

The platform retains monitoring data to provide transparency on past performance:

• Daily History: At the end of each calendar day (UTC), a snapshot of the day's monitoring results is archived. This includes uptime percentages, response times, and status change events for every tracked service. Historical daily records are browsable on each monitor's detail page, the number of days available to be viewed are not guaranteed.
• Hourly Timeline: The monitor detail page displays a 24-hour candle chart showing the dominant status for each hour of the current day, with yesterday's data shown as reference candles for comparison.
• Counters & Metrics: Aggregate counters (total checks, successful checks, failed checks) are maintained per monitor and reset or rolled over on a daily cycle.

User Monitors

Authenticated users may create personal monitors to track their own services via HTTP or API checks. User monitor history, including up to 48 hours of rolling status change data, is stored separately and is visible to the monitor owner, deployment managers, and platform administrators (unless the monitor is set to public). Users with approved API access can additionally configure custom check intervals (1–5 minutes) and consecutive failure thresholds (1–10 failures before alerting). API access applications may be closed at certain times or only open at the staff’s discretion.

Alerting & Notifications

Webhook notifications are sent for the following events: service downtime, service recovery, scheduled maintenance, and incident updates (creation, stage changes, and resolution). Notifications can be delivered through:

• Discord Webhooks: Status change and incident notifications posted to a Discord channel. Incident notifications on Discord are automatically edited in-place as the incident progresses through stages, if the original message can’t be found, a new message is sent instead.
• Slack Webhooks: Notifications formatted for Slack using Block Kit, posted to a configured Slack incoming webhook URL.
• Generic Webhooks (API access required): JSON payloads sent via HTTP POST to any external endpoint. A signing secret can be set in Alerts. Signed deliveries include X-Status-Timestamp and X-Status-Signature headers; the signature is HMAC-SHA256 over timestamp.body, formatted as sha256=<hex digest>. Verify it against the exact raw body and reject stale timestamps to prevent replay. Generic webhooks require approved API access; approved users receive a higher webhook limit (5 vs. 2).

Webhook notification formatting may differ slightly between platforms, and some internal metadata may be redacted from non-Discord deliveries. Notifications for hidden or SFTP sub-component monitors are suppressed. Notifications can also be triggered by manual status changes made by staff, and may be suppressed when a monitor has a status lock or forced reason applied.

Alert Delay: To prevent spam and reduce false positives caused by transient network issues or brief service flaps, alerts may be intentionally delayed by up to 3 minutes before being dispatched. This means a service may need to remain in a changed state (e.g., offline) for a short period before a notification is triggered. This delay helps ensure that alerts are meaningful and actionable, rather than firing on every momentary blip.

Sub-Components & Dependencies

Node monitors (TCP-type monitors with SFTP enabled) depend on an associated SFTP sub-component monitor that checks connectivity on port 2022. If the SFTP sub-component is down, the parent node monitor’s status will reflect this as degraded or issues. Monitors can also have explicit dependency relationships, if a monitor depends on another monitor and that dependency goes offline, the dependent monitor’s status may be marked as having issues accordingly. These relationships ensure the status page accurately reflects cascading infrastructure problems.

Data Accuracy

Our monitoring infrastructure runs checks at regular intervals with configurable failure thresholds and retry logic designed to minimize false positives. Component monitors use multiple condition checks before declaring a service down. The platform is generally accurate and reflects the real operational state of Bot-Hosting’s infrastructure. That said, brief discrepancies can occur due to factors outside our control, network routing, regional DNS propagation, or transient packet loss may cause a service to appear down momentarily when it’s reachable from other locations. No automated monitoring system is perfect, but we aim to keep reported status as close to reality as possible. Users can report monitors, staff can review them and manually change status or post an incident if confirmed.

Uptime During Outages: During active outages, incidents, or periods of service degradation, displayed uptime percentages, latency averages, and other aggregate metrics for individual monitors, summary views, and overall system status may be temporarily outdated or not reflect the current situation in real time. These metrics are recalculated periodically and may take some time to fully update even after an issue has been resolved. Users should refer to the active incident timeline and status indicators for the most current information during ongoing events.