Credential encryption
Integration credentials are encrypted with AES-256-GCM using a derived application key, unique initialization vectors, and authentication tags.
Write-only secrets · Versioned ciphertext
Security and Trust Center
Security you can examine.
A transparent view of how Uptime protects accounts, separates workspaces, handles sensitive credentials, records administrative activity, and approaches the controls still being built.
Control overview
Current postureACTIVE
Credential vault
AES-256-GCM · authenticated ciphertext
ENFORCED
Workspace boundary
Membership and permission checks
4 ROLES
Access model
Owner · Admin · Member · Viewer
REDACTED
Audit evidence
Actor · target · request · outcome
This page distinguishes implemented controls from work in progress. No third-party certification is claimed without evidence.
Implemented controls
Controls grounded in the product today.
These are implementation-backed controls—not aspirations or compliance shorthand. Scope is stated precisely so your team can evaluate what each control protects.
Tenant boundaries
Organization-scoped requests require an authenticated session, active membership, and permission for the requested action.
Membership + permission + scoped query
Role-based access
Owner, administrator, member, and viewer roles separate management privileges from read-only access across workspace resources.
Four workspace roles
Administrative audit trail
Platform changes can retain actor, action, target, request, network, and before/after context while redacting sensitive field names.
Sensitive values redacted
Session protection
Production authentication uses secure cookies, trusted origins, account-disable checks, and session revocation after password resets.
Secure production cookies
Public data minimization
Public status responses use customer-facing component data and derived identifiers without exposing monitor targets or organization records.
Targets remain private
Tenant isolation
Access is decided before data is queried.
A workspace identifier alone is not authorization. Protected API routes establish the user session, verify organization membership, evaluate the role’s permission, and constrain the database operation to that organization.
Public status-page routes use a separate response shape designed to expose customer-facing health information without returning monitor targets or organization metadata.
01
Session
Authenticated user
02
Membership
Organization match
03
Permission
Action allowed
04
Scoped query
Tenant constrained
Authorized request
Unauthorized, disabled, or insufficiently privileged accounts are rejected before the protected operation proceeds.
Data handling
Data has a defined operational purpose.
Uptime stores the account, workspace, telemetry, and delivery data needed to operate the service. Sensitive credentials follow a narrower storage and retrieval path.
Retention policy status
A universal deletion schedule is not yet published. Formal retention and deletion commitments are in progress.
Data class
Account and membership
Operational purpose
Authentication, organization access, invitations, and support
Current handling
Accessed through authenticated, role-aware operations
Data class
Monitoring telemetry
Operational purpose
Availability history, incident evidence, charts, and reports
Current handling
Organization-scoped; historical observations survive region retirement
Data class
Integration credentials
Operational purpose
Deliver notifications to configured destinations
Current handling
Application-encrypted and never returned in full after storage
Data class
Public status content
Operational purpose
Communicate component health, maintenance, and incidents
Current handling
Explicitly selected content with internal targets removed
History preservation
Retiring a probe region does not erase the monitoring observations already associated with customer history.
Token minimization
Probe credentials and status-subscriber verification tokens are compared using stored hashes rather than plaintext token records.
Public presentation
Status-page owners choose a visible 30, 60, or 90-day history; that display setting does not imply deletion of source telemetry.
Control maturity
Evidence before badges.
Security programs become less useful when roadmap items are presented as finished controls. This register shows the distinction plainly and will evolve with the platform.
Current·implemented now
In progress·actively being formalized
Planned·future capability
Organization-scoped authorization
Membership and role permissions are evaluated before workspace data access.
Encrypted integration vault
AES-256-GCM protects stored provider credentials at the application layer.
Platform audit records
Administrative changes retain traceable context with sensitive-key redaction.
Published retention schedule
Documented deletion windows and customer-facing retention commitments.
Formal incident-response policy
Published severity, escalation, notification, and post-incident commitments.
Self-service session management
User-visible active sessions with individual and global revocation controls.
Multi-factor authentication
Additional account verification beyond the primary password flow.
Enterprise identity
SAML-based SSO and automated identity lifecycle management.
Independent compliance program
Evidence collection and third-party assessment before any certification claim.
Incident handling
From report to containment.
Current operational tooling provides service heartbeats, platform audit evidence, account controls, and notification-delivery context. A formal external incident-response and notification policy is still being documented.
Step 1
Receive and triage
Route the report to the security category and establish affected scope.
Step 2
Preserve evidence
Use request identifiers, audit context, sessions, and service health to investigate.
Step 3
Contain and remediate
Revoke access, disable affected accounts or credentials, and correct the vulnerable path.
Step 4
Communicate and learn
Notify affected parties as appropriate and retain remediation follow-through.
Responsible disclosure
If you believe you found a security issue, send a private report with enough detail for the team to reproduce and assess it.
Please include
- Affected route, feature, or integration
- Reproduction steps and expected impact
- Supporting screenshots or sanitized request details
Testing boundaries
Do not access another customer’s data, include real user records, perform destructive tests, or degrade service availability. A public bug-bounty program and response-time SLA are not currently offered.
Need a deeper review?
Bring us your security questions.
Tell us about your architecture, procurement, or data-handling requirements and we will answer with the current platform scope.