Security & trust

The monitoring service you trust to watch your systems has to be worth trusting itself. This page is how PylonMon is built and operated, in enough detail for a security review — every item is a live property of the service, not a roadmap slide. Need it as a document? Request the security packet.

Architecture

PylonMon is one static Go binary, run as an active-active pair behind a load balancer, backed by a managed PostgreSQL service, with an independent prober in a second region. Nothing in the path is shared with any other product, and nothing runs inside your network unless you install the open-source agent.

            YOUR INFRASTRUCTURE
     endpoints · hosts · cron jobs · logs
          │ (outbound only)  │ (we poll)
          ▼                  ▼
   pylon-beacon ──────▶  PylonMon app nodes  ◀──── second-region prober
   (open source, MIT)     us-west, active-active     us-east, stateless
                          behind a load balancer     confirms outages
                                  │
                                  ▼
                          managed PostgreSQL
                          state · rollups · logs (separate database)
                                  │
                                  ▼
                          alert delivery
     email · SMS · voice · Slack · Teams · Discord · webhooks · PagerDuty · push

• Checks originate from our nodes in the US West region; paid-plan outages are re-checked from the US East prober before anyone is paged. The prober is stateless: it receives a check to run and returns a verdict, and it holds no customer data at rest.
• The agent connects out to PylonMon over TLS with a workspace-scoped key. It opens no inbound port, runs no shell on our behalf, and its source is public on GitHub for your security team to read.
• Alert delivery goes through the providers listed under subprocessors, each with the minimum data needed to deliver (an address, a phone number, the alert text).

Where data lives

• Region: United States. Application nodes, the load balancer and the database run in the US West (Fremont, CA) region of Akamai Cloud (Linode); the confirming prober runs in US East (Newark, NJ). We do not currently offer EU residency — ask if you need it, it is on the list.
• Database access is restricted by IP allow-list to the application nodes only; nothing else can reach it, and every application query is scoped to the workspace it belongs to.
• What we store: monitor definitions and results, alert and incident history, the vitals and log lines your agent or collector ships us, channel addresses, and billing metadata. We store no card numbers (Stripe holds them) and never sell or share data — it is in our terms.
• Retention: raw results and rollups per plan (90 days at most), log lines 1–90 days by plan, and the daily partition janitor drops what has aged out. Closed accounts are purged after the retention window; deletion is self-serve.
• In transit: TLS from your browser to us, from us to your monitored endpoints, from the agent to us, and between our nodes and the database.

Accounts & access

• Passwords are never stored — only salted PBKDF2 hashes, compared in constant time.
• Two-factor auth (TOTP) with single-use recovery codes, on every plan.
• Google sign-in and enterprise SSO (OIDC) — bring Okta, Entra ID, Auth0, Keycloak, or Google Workspace. Members created through your IdP are IdP-managed: password sign-in is disabled for them, password resets are refused, and their sessions are capped at 24 hours — offboarding someone at your IdP ends their PylonMon access within a day.
• Roles (owner / admin / write / read) scope what each member can touch; sessions are HttpOnly cookies.
• API keys are per workspace, scoped (full, read-only, ingest-only, agent), rotatable, and the master switch revokes all of them at once. Agent-scoped keys can note and resolve incidents but can never change a monitor or a channel — the leash for a BYO-AI responder.
• Audit trail: every change made by a member — monitors, channels, escalation ladders, keys, status page, acknowledgements — is recorded with who and when and is visible in the workspace's event history.
• Operator access: the operators have an admin console for the fleet (plan, suspension, usage). It does not expose customer credentials, and operator actions are logged as events too.

Operations

• Off-site by design: PylonMon runs on independent infrastructure, outside your network — it keeps watching (and paging) when your environment is dark.
• Redundant nodes: an active-active pair behind a load balancer. Both nodes serve traffic and run checks; the scheduler lease moves between them, so losing one node loses no checks.
• Deploys are rolling and pinned: every release is a CI-built image tagged by commit, deployed one node at a time after draining it from the balancer, with the second node still paging. A deploy that changes stored data ships the reader first and the writer later, so both versions can run side by side.
• We watch ourselves with PylonMon: external checks on the public endpoints, the second-region prober on the API, and an agent on each node — the operator is paged the same way you are.
• Least surface: a single static binary, no third-party analytics or tracking scripts on the product, first-party cookies only; the marketing site uses first-party visit counting, not a tracker.
• Payments: Stripe handles every payment; card numbers never touch PylonMon's servers. Mail: our sending domains enforce SPF, DKIM and a strict DMARC reject policy, so mail claiming to be PylonMon that isn't gets refused by your provider.

Backups & continuity

• Backups are taken automatically by the managed PostgreSQL service and are reachable only through it — never from the application nodes.
• Losing a node: the other node keeps serving and checking; nothing is lost because every state change is persisted before it is acknowledged.
• Losing the second-region prober: we fail open — after three missed cycles the primary region takes over confirmation, and the affected monitors say so in their events. A dead prober can never mute an alert.
• Losing the primary region: checks and paging stop until the region or a rebuilt fleet returns; the infrastructure is declared as code and rebuilds from the last backup. We do not yet run a warm standby in a second region for the application itself, and we say so rather than imply otherwise.

Incident response

• A service incident opens on our status page as soon as we know, with updates until it is resolved and a note on what happened.
• If an incident touched your data — anything beyond availability — we email the workspace owners with what was affected, when, and what we did, without waiting for you to ask.
• Enterprise support requests are answered by an engineer, by severity: an outage within the hour, a degradation within four, everything else next business day.

Subprocessors

The third parties that handle customer data on our behalf, what they see, and where. We keep this list current; if you need notice of changes, ask under the security packet below and we will add you to it.

Vulnerability disclosure

If you find a security issue in pylonmon.com, the API, or pylon-beacon, tell us at security@pylonmon.com — reports land in front of an engineer. We also publish /.well-known/security.txt.

• In scope: pylonmon.com, api endpoints under it, the portal, the status pages, and the pylon-beacon agent and installer.
• Out of scope: denial of service, volumetric testing, social engineering, physical access, and issues in the third parties above (report those to them).
• What to expect: acknowledgement within two business days, a triage decision within seven, and a fix or a stated plan before public disclosure. We ask for up to 90 days of coordinated disclosure and we credit reporters who want credit.
• Safe harbor: good-faith research within this scope, that avoids privacy violations, data destruction and service disruption, will not be met with legal action.
• Bounty: none at this time; we say so rather than let you assume one.
• Agent vulnerabilities get a release with a changelog entry and, where warranted, a CVE.

Compliance

PylonMon is not SOC 2 audited yet, and we will not claim otherwise. The controls a SOC 2 review looks for — access scoping, MFA, audited changes, backups, encryption in transit, incident handling, vendor inventory — are the ones described on this page, and we will walk your security review through them directly. A SOC 2 Type I engagement starts when a customer needs it as a condition of contract.

Request the security packet

Email security@pylonmon.com with the subject "Security packet" and we will send, within two business days: this page as a dated PDF, our answers to the common security questionnaires (SIG Lite / CAIQ style), the architecture diagram, the subprocessor list, our data processing agreement, and our incident-response and backup summaries. An engineer joins a video call on request.