SignalFly
How it worksSetupFeatures
Log inGet started
Home/Legal/Privacy Policy

Privacy Policy

How SignalFly collects, processes, isolates, and protects developer application telemetry and contextual feedback.

Version 1.0Last Updated: October 10, 2026
Privacy PolicyTerms of Service
Contents
  • 1. Introduction and Scope
  • 2. Information We Collect
  • 3. How Information Is Used
  • 4. Widget and Customer Application Data
  • 5. Monitoring and External Services
  • 6. Data Sharing and Processors
  • 7. International Data Transfers
  • 8. Data Retention and Deletion
  • 9. Security Measures
  • 10. User Rights and Choices
  • 11. Children's Privacy
  • 12. Changes and Contact Information
  • 13. Launch Decisions & Disclosures
Need assistance?
View Setup Guide →
â„šī¸ Operational Transparency Notice
This Privacy Policy accurately reflects the actual technical architecture, database schema, telemetry models, and third-party integrations of SignalFly V1. It does not advertise unimplemented capabilities, claim unverified compliance certifications, or substitute for formal legal counsel. Key corporate and legal placeholders requiring product owner confirmation prior to commercial launch are explicitly highlighted in Section 13.

1. Introduction and Scope

SignalFly ("SignalFly", "we", "us", or "our") provides an application health monitoring and contextual user feedback platform designed for software engineers, product builders, and technical teams. SignalFly combines automated HTTP uptime monitoring, automated incident tracking, real-time alert dispatching, and an embeddable client-side feedback widget to give teams a clear, unified view of application reliability and real user friction.

This Privacy Policy applies to personal data and technical telemetry processed through:

  • The SignalFly web application and marketing website hosted at https://signalfly.io and associated staging environments.
  • The SignalFly REST API and background worker processing services.
  • The SignalFly client-side feedback widget bundle (@signalfly/widget / widget.js) embedded by developers into their web applications.
  • Public feedback ingestion and attachment upload endpoints.

Service Operator & Legal Identity: SignalFly is currently developed and operated as an independent software product based in the Federal Republic of Nigeria. As documented in Section 13, the formal registered corporate legal entity, registration number, and registered business address have not yet been established in the codebase and must be confirmed by the product owner prior to public commercial launch.

2. Information We Collect

We strictly collect and process data necessary to provide application health monitoring and user feedback ingestion. We distinguish between information submitted by developers, information submitted by end-users of monitored applications, and information collected automatically by our systems.

2.1 Account and Identity Information (Submitted by Developers)

When you create a SignalFly account or manage workspace access, we collect:

  • Email Address & Name: Your primary work email address and optional display name.
  • Authentication Credentials: If registering via email and password, we store an industry-standard cryptographic password hash generated using bcrypt (salt rounds: 10). Plaintext passwords are never logged, stored, or accessible to us.
  • Social Authentication Identifiers: If you sign in via "Continue with Google" or "Continue with GitHub", we receive and store your provider account identifier (Google sub or GitHub id) and verified primary email address. We do not receive or store your Google or GitHub account passwords.
  • Workspace & Membership Hierarchy: Workspace name, generated URL slug, and role assignments (OWNER or MEMBER).

2.2 Application Projects and Monitoring Configuration

When configuring projects and monitors within a workspace, we store:

  • Project Metadata: Project display name, optional description, target application URL, and repository provenance paths.
  • Public Ingestion Keys: A cryptographically generated public project key (prefixed with sf_pk_) used exclusively by the embedded widget to route feedback submissions to the correct project.
  • HTTP Monitor Configurations: Target endpoint URL, HTTP method (GET), check interval (default 300 seconds; minimum 600s on Free, 300s on Pro), request timeout (10 seconds), expected HTTP status code (default 200), consecutive failure threshold (default 3 checks), consecutive recovery threshold (default 1 check), and active/paused status.

2.3 Health-Check Telemetry and Incident Records (Automatically Generated)

Our background monitoring engine executes scheduled HTTP health checks and records:

  • Health Check Results: Timestamp of check, success/failure boolean, HTTP response status code, round-trip latency in milliseconds (responseTimeMs), and network error codes or error messages (e.g., ECONNREFUSED, ETIMEDOUT).
  • Incident Records: Incident state (OPEN or RESOLVED), started timestamp, detection timestamp, resolved timestamp, consecutive failure count, recovery count, and automated incident summary.

2.4 Feedback Submissions and Context (Submitted via Widget)

When an end-user of a developer's application interacts with the embedded SignalFly feedback widget and submits a report, the widget transmits:

  • Feedback Message: Text content submitted by the user (up to 5,000 characters).
  • Feedback Category: User-selected category (BUG, SUGGESTION, or GENERAL).
  • Triage Status: Lifecycle triage state (NEW, REVIEWING, or RESOLVED).
  • Automated Page Context: The active URL where feedback was triggered (pageUrl, up to 2,048 characters) and page document title (pageTitle, up to 500 characters).
  • Browser and Viewport Context: Detected browser family string (derived from the browser User-Agent, max 255 characters) and viewport dimensions (viewportWidth and viewportHeight in pixels).
  • Screenshots and Attachments (Optional): If the end-user explicitly elects to attach a screenshot, the widget captures an image via the browser screen capture API (navigator.mediaDevices.getDisplayMedia) following explicit user permission, or via manual image file upload (PNG, JPEG, WebP; maximum 5MB). We store the attachment storage key, file name, MIME type, and file size in bytes.

2.5 Third-Party Integrations

  • Telegram Alerts: Workspace-connected Telegram Chat ID, bot connection status, and delivery logs for MONITOR_DOWN, MONITOR_RECOVERED, and FEEDBACK_CREATED notification events, including delivery timestamps, payload summaries, error messages upon delivery failure, and read timestamps (readAt).
  • GitHub App Integration: When connecting a workspace to the SignalFly GitHub App, we store the GitHub installation ID, account login, account type, and account avatar URL. When discovering applications, SignalFly inspects repository file trees in real time to suggest deployable applications; SignalFly does not clone, mirror, or store customer source code.

2.6 Subscription and Billing Metadata

We store your workspace subscription plan tier (FREE or PRO), subscription lifecycle status (ACTIVE, TRIALING, PAST_DUE, or CANCELED), and billing cycle start/end dates. Because paid checkout and payment processing (planned via Paystack) are not yet live, SignalFly does not currently collect, store, or process credit card numbers or banking credentials.

2.7 Technical Logs, Rate Limiting, and Security Events

To maintain service stability, public feedback ingestion is rate-limited in memory (10 requests per minute per IP address and project key). OAuth state tokens (10-minute TTL) and one-time session exchange tickets (30-second TTL) are stored ephemerally in Redis. Standard operational server error logs are recorded for diagnostics.

What We DO NOT Collect: SignalFly does not perform session replay, screen recording without explicit permission, keystroke logging, form input scraping, third-party behavioral advertising tracking, or marketing cookie profiling.

3. How Information Is Used

We use the data collected strictly for the following operational purposes:

  • Core Service Delivery: Authenticating users, enforcing workspace data isolation, providing the web dashboard, and managing project configurations.
  • Uptime Monitoring: Dispatching automated HTTP checks to your configured endpoints, recording response times, computing incident thresholds, and updating uptime metrics.
  • Incident and Alert Delivery: Generating and delivering real-time alerts to your configured Telegram destination when endpoints fail or recover.
  • Feedback Management: Ingesting, organizing, categorizing, and presenting user-submitted feedback and screenshots to authorized workspace members.
  • Entitlement Enforcement: Enforcing plan limits (Free: 3 projects, 5 monitors, 10-minute minimum interval, 100 feedback submissions/mo, 25 attachments/mo, 7-day notification history; Pro: unlimited projects/monitors, 5-minute interval, 90-day notification history).
  • Security and Abuse Prevention: Enforcing API rate limits, mitigating denial-of-service attempts, preventing cross-tenant access, and verifying session tokens.
  • Platform Maintenance: Diagnosing server errors, monitoring system performance, and ensuring reliable background worker execution.
đŸ›Ąī¸ AI Training Disclaimer
SignalFly does NOT use customer application URLs, feedback messages, screenshots, or telemetry to train artificial intelligence models or public machine learning algorithms. Future AI capabilities (such as feedback summarization or incident briefs) will operate on authorized, workspace-scoped records only, exclude screenshot binaries, and require explicit customer opt-in.

4. Widget and Customer Application Data (Developer Responsibilities)

Developers integrate SignalFly into their applications by embedding our client-side script (widget.js). In this context, the developer or organization operating the host application acts as the Data Controller, and SignalFly acts as a Data Processor (or service provider).

4.1 Scope of Widget Ingestion

The SignalFly feedback widget is passive until an end-user explicitly clicks the widget trigger and submits a feedback report. The widget does not monitor browsing history, intercept form inputs across the host page, or inspect cookies from the host application.

4.2 Screenshot Capture Consent

When an end-user elects to attach a screenshot, the widget utilizes the browser-native navigator.mediaDevices.getDisplayMedia API. This triggers a browser-level permission dialog requiring the end-user to explicitly choose which tab, window, or screen to share. The user can preview and delete the captured image before submitting.

4.3 Developer Obligations

Developers who embed the SignalFly widget are responsible for:

  • Providing appropriate privacy notices to their end-users disclosing the collection of feedback, technical context (URL, browser, viewport), and optional screenshots.
  • Obtaining any legally required consents under applicable privacy laws (including GDPR, NDPA, and CCPA) prior to collecting end-user feedback.
  • Instructing their end-users not to submit sensitive personal data, authentication passwords, payment card numbers, health records, or confidential proprietary secrets in feedback messages or screenshot captures.

5. Monitoring and External Services

SignalFly sends automated HTTP requests to developer-configured target endpoints. Developers are solely responsible for ensuring they own or have explicit authorization to monitor configured URLs.

To deliver our service reliably, SignalFly relies on modern, managed infrastructure providers:

Infrastructure ProviderRole in SignalFlyData Processed
Vercel Inc.Next.js web application hosting & static widget CDN deliveryWeb UI traffic, client IP addresses, web request logs
Render Services Inc.API server hosting, BullMQ background workers, managed Redis queuesAPI traffic, scheduled health-check jobs, notification queues, ephemeral tokens
Neon Inc.Serverless PostgreSQL relational database hostingUser accounts, workspaces, monitors, checks, incidents, feedback, integration configs
Cloudflare Inc. (R2)Private S3-compatible object storage for attachmentsScreenshot image binaries (stored privately; accessible only via authenticated dashboard streams)
Telegram Messenger Inc.Telegram Bot API for real-time notification dispatchConfigured Telegram Chat IDs, notification alert payloads (down/recovery/feedback events)
GitHub Inc.OAuth login & GitHub App repository application discoveryGitHub account ID, verified email, repository file tree inspection (no code stored)
Google LLCGoogle OAuth 2.0 developer loginGoogle account ID (sub), verified email

Integration Status: Only Telegram, GitHub, and Google integrations are currently operational. Email, Slack, Discord, and WhatsApp alert channels are planned roadmap integrations and are not active.

6. Data Sharing and Processors

SignalFly does never sell, rent, or trade personal data or customer telemetry to third parties or data brokers.

We share data solely with the infrastructure service providers listed in Section 5 to the extent strictly necessary to host, operate, and maintain the service. Each provider processes data pursuant to service agreements and privacy standards.

We may also disclose information if required to do so by applicable law, lawful subpoena, or binding legal process, or to protect the safety, security, and integrity of SignalFly, our users, or the public.

7. International Data Transfers

SignalFly is operated from Nigeria. Our managed cloud infrastructure providers (Vercel, Render, Neon, Cloudflare) operate data centers and edge servers internationally, including in the United States and the European Union.

When you access SignalFly or use our monitoring and widget services, your data may be transferred to, stored, and processed in jurisdictions other than your country of residence. Data protection laws in these jurisdictions may differ from those in your home jurisdiction. Formal cross-border transfer documentation (such as Standard Contractual Clauses and Nigerian Data Protection Act adequacy requirements) is documented in Section 13 for legal review prior to formal commercial onboarding.

8. Data Retention and Deletion

We retain data only as long as necessary to provide the service and fulfill legal obligations:

  • Account and Workspace Data: Retained for the active lifetime of your account.
  • Notification History (Plan-Based Retention): Free tier workspaces access 7 days of notification event history; Pro tier workspaces access 90 days. Records older than the applicable plan retention window are filtered and hidden from the user-facing dashboard interface.
  • Health Check and Incident Records: Stored alongside active monitors to provide historical uptime and latency trends within the dashboard.
  • Feedback and Screenshots: Stored within your project workspace until manually triaged or until the project/workspace is deleted.
  • Deletion Mechanics: The database schema enforces cascade deletion (onDelete: Cascade) across all child entities (projects, monitors, checks, incidents, feedback, attachments, notifications) when a parent entity is deleted. However, because self-service account deletion is not currently implemented in the web UI, account and workspace deletion requests must be submitted directly to our support team.
  • Backup Cycles: Encrypted operational database backups maintained by our cloud database provider (Neon) are automatically rotated and overwritten in accordance with standard disaster recovery lifecycles (typically 7 to 30 days).

9. Security Measures

We implement technical and organizational security controls to protect your data against unauthorized access, alteration, disclosure, and destruction:

  • Multi-Tenant Workspace Isolation: Every API endpoint enforces strict workspace-level authorization guards (WorkspaceMemberGuard) to ensure users can access only data belonging to their verified workspace.
  • Password Security: Passwords are encrypted using bcrypt hashing with salt rounds of 10.
  • Enforced Secret Validation: Production deployments enforce startup validation requiring JWT and storage signing secrets to be at least 32 characters long and rejecting development fallback strings.
  • Private Object Storage: Screenshot attachments in Cloudflare R2 are stored in a private bucket with no public URL access. Uploads require time-limited presigned URLs with HMAC replay verification, and viewing streams through authenticated API endpoints.
  • Encrypted Transport: All data in transit is encrypted using modern TLS (HTTPS) across web dashboards, API endpoints, database connections, and managed Redis queues (rediss://).
  • Rate Limiting: In-memory rate limiters protect public feedback ingestion endpoints against volumetric abuse and spam.

Disclaimer: While we implement reasonable and verified security controls, no method of transmission over the Internet or electronic storage is 100% secure. We cannot guarantee absolute security.

10. User Rights and Choices

Depending on your jurisdiction (such as under the Nigeria Data Protection Act [NDPA], the General Data Protection Regulation [GDPR], or other applicable laws), you may have the following rights:

  • Right of Access: Request a copy of the personal data we hold about you.
  • Right to Rectification: Update or correct inaccurate or incomplete account details.
  • Right to Erasure: Request the deletion of your account and personal data.
  • Right to Restriction & Objection: Object to or restrict certain processing activities.
  • Right to Data Portability: Request export of your feedback and project data in a structured format.

10.1 Self-Service Account Controls

Within the SignalFly dashboard, you can manage your profile name, change your password, connect or disconnect Google and GitHub accounts (Settings → Account), and connect or remove Telegram notification integrations (Settings → Notifications).

10.2 Exercising Statutory Rights

To submit a formal access, deletion, or privacy request, contact us at privacy@signalfly.io. We will verify your identity and respond within statutory timeframes (typically within 30 days).

11. Children's Privacy

SignalFly is a developer observability and product feedback tool intended solely for software developers, business professionals, and adult users. We do not knowingly collect personal data from children under the age of 16 (or applicable age of majority in your jurisdiction). If we discover that a child has provided us with personal information, we will promptly take steps to delete that data.

12. Changes and Contact Information

We may update this Privacy Policy from time to time to reflect product enhancements, infrastructure updates, or legal requirements. When changes are made, we will update the "Last Updated" date at the top of this document. Material changes will be communicated through dashboard notices or email notifications to registered account owners.

If you have questions, concerns, or requests regarding this Privacy Policy or our data practices, please reach out to us:

  • Email: privacy@signalfly.io
  • Product Website: https://signalfly.io

13. Launch Decisions & Owner Disclosures

📋 Mandatory Pre-Launch Legal & Commercial Checklist
The following legal, business, and operational determinations are currently pending formal establishment by the SignalFly product owner prior to commercial public launch:
  • Legal Business Entity: A formal registered corporate name (e.g., Limited Liability Company in Nigeria or international entity) and official registered business address must be established and updated in Section 1.
  • Dedicated Privacy & Support Inboxes: Verified support and privacy email addresses (e.g., privacy@signalfly.io and support@signalfly.io) must be provisioned on production mail servers.
  • Data Processing Addendum (DPA) & Subprocessor List: A binding standard DPA and subprocessor schedule must be published for business customers subject to GDPR and NDPA.
  • Self-Service Account Deletion UI: A self-service account deletion and workspace purge workflow should be scheduled in the dashboard settings.
  • Automated History Pruning: A background cron job should be implemented to permanently purge notification events older than 7 days (Free) and 90 days (Pro), moving beyond query-level filtering.
  • Commercial Billing Terms: Formal Paystack payment terms, local tax handling (e.g., Nigerian VAT), recurring billing policies, and refund rules must be finalized before enabling paid checkout.
SignalFly

Application health and user feedback, connected.

Product
  • How it works
  • Setup
  • Features
  • Security
Account
  • Login
  • Get started
Legal
  • Privacy Policy
  • Terms of Service
Š 2026 SignalFly. All rights reserved.
Privacyâ€ĸTermsâ€ĸBuilt for developer and product teams.