Architecture Transparency
Uptimer uses deliberate platform patterns to keep monitoring predictable under load, secure by default, and auditable for enterprise reviews. This page explains the core terminology, acronyms, and implementation strategies in plain language.
Uptimer is built as a modern .NET platform where C# powers both backend services and the interactive web UI. This gives one coherent engineering stack for faster delivery, stronger security consistency, and simpler long-term maintenance.
| Layer | Technology | What it does in Uptimer | Why it matters |
|---|---|---|---|
| Runtime | .NET 10 |
Hosts the web app, API endpoints, background jobs, and core services. | High-performance runtime with enterprise-grade tooling and observability. |
| Web/API | ASP.NET Core Minimal APIs |
Implements auth, monitoring, billing, export, compliance, and public-status endpoints. | Clean endpoint design with strong policy enforcement and fast iteration speed. |
| Frontend | Blazor (Interactive Server) |
Drives interactive dashboards, admin controls, and engineering evidence views. | Rich UX while keeping core business logic and security checks server-side. |
| Data Access | Entity Framework Core |
Handles data modeling, migrations, and query composition for platform data. | Type-safe data access with predictable schema evolution. |
| Databases | SQLite and PostgreSQL |
Supports lightweight local deployments and scalable network database deployments. | Flexible deployment paths from single-node to larger multi-tenant environments. |
| Security | Cookie Auth, OpenID Connect, anti-forgery, rate limiting |
Secures identity, sessions, sensitive workflows, and request traffic patterns. | Defense-in-depth against account abuse and web attack classes. |
| Observability | Serilog |
Produces structured application logs for operations and investigation workflows. | Improves troubleshooting speed and audit readiness. |
| Integrations | MailKit, payment/webhook integrations |
Powers email verification, operational notifications, and billing lifecycle events. | Connects core reliability workflow to customer communication and revenue operations. |
| AI | ML.NET, Rule-based intelligence & Heuristic projection |
Powers Summaries, Anomoly Detection and data-based predictions | Allows for trust-worthy predictions and quick summaries of monitor health. |
Uptimer is implemented as a modern C# web platform using ASP.NET Core minimal APIs with explicit endpoint grouping, policy controls, and typed responses. This keeps the service fast to evolve while staying strict on security and boundaries.
What it is: Endpoint groups are organized by domain (auth, monitors, billing, exports, audit, public status, compliance, setup, and SCIM).
Why it matters: This structure keeps the API surface understandable for teams, easier to audit, and safer to extend without cross-domain leakage.
What it is: Endpoints use strongly typed request/response models and async handlers rather than loosely typed payload plumbing.
Why it matters: Strong typing catches integration errors earlier and improves long-term reliability as API complexity grows.
What it is: Middleware includes rate limiting and anti-forgery enforcement, layered with authentication and authorization policies.
Why it matters: Critical controls are standardized at pipeline level so defenses are consistent across endpoints, not left to ad hoc implementation.
What it is: Tenant-admin APIs and public status APIs are intentionally split, with separate query paths and exposure rules.
Why it matters: This is central to enterprise trust: public observability is enabled without weakening private workspace confidentiality.
The frontend uses Blazor interactive server components so UI experiences stay rich and reactive while business logic remains on the server. The result is a highly capable product UI without duplicating core rules in a separate JavaScript-heavy client application.
What it is: Razor components render quickly, then become interactive for live controls, telemetry refresh loops, and admin workflows.
Why it matters: Users get dynamic behavior while engineering teams keep sensitive logic and policy checks centralized on the server.
What it is: Reusable C# components power pages like dashboard, stats evidence, configuration forms, and security workflows.
Why it matters: Shared components reduce UI drift and make improvements faster, safer, and more consistent across the product.
What it is: Product pages expose engineering context directly in the interface (evidence tags, benchmark classes, control explanations).
Why it matters: Complex reliability and security concepts become decision-ready for buyers, leadership, and operations teams.
What it is: Shared language and patterns across API, background services, and frontend components.
Why it matters: Fewer translation layers means less mismatch risk between UI behavior and backend enforcement.
Uptimer includes local/offline intelligence features designed for explainability and predictable operations. These capabilities are built into the platform runtime rather than delegated to external paid model APIs.
What it is: Generated monitor health summaries based on recent checks, event history, and monitor configuration.
Why it matters: Gives teams faster operational context without exposing private payloads on public pages.
What it is: Deterministic summary generation from status events and telemetry around outages and recoveries.
Why it matters: Reduces manual triage effort and improves consistency in stakeholder communications.
What it is: Statistical detection of unusual latency windows from observed check performance over time.
Why it matters: Surfaces degradation patterns before they become full incidents.
What it is: Local ML scoring for incident risk, likely incident type, and short-horizon uptime forecasts.
Why it matters: Helps teams shift from reactive monitoring to proactive reliability planning.
What it is: Initial boot training, nightly retraining, and hourly prediction snapshot scoring.
Why it matters: Keeps model outputs current while maintaining a stable and auditable operating schedule.
What it is: Sanitized inputs, bounded processing windows, sparse-data fallback heuristics, and no autonomous config mutation.
Why it matters: Preserves control and transparency so AI output remains operational guidance, not opaque automation.
For live model/retraining status and detailed AI operating behavior, see AI Transparency.
What it is: A fairness-aware scheduler that loads due monitors, buckets them per tenant, and selects work items in round-robin tenant order.
Why it matters: Prevents one noisy tenant from dominating execution slots and keeps progress balanced across owners.
What it is: Hard limits on in-flight checks globally, per tenant, and per host, combined with a bounded execution queue and de-duplication by monitor ID.
Why it matters: Protects availability by turning overload into managed delay while avoiding duplicate in-flight checks for the same monitor.
What it is: Cloud always exposes built-in locations global-1..3; configured node-* locations are added dynamically and routing chooses the least-stress location within each tenant's plan-allowed location slots.
Why it matters: Keeps auto placement capacity-aware while still enforcing billing-plan boundaries for location access.
What it is: Node services periodically report queue pressure and execution capacity to cloud; cloud also reports global location stress from local queue pressure.
Why it matters: Routing decisions are based on live load telemetry instead of static round-robin assumptions.
What it is: Time-window aggregation of check outcomes and latency into summarized operational metrics for dashboards and reports.
Why it matters: Reduces noise, makes trends visible, and keeps data useful for both incident response and capacity planning.
What it is: Configurable data-lifecycle rules that preserve operational history for a defined period and expire stale records.
Why it matters: Balances compliance, storage cost, and forensic usefulness without unbounded data growth.
Queueing is implemented as one bounded, de-duplicated execution queue per running process. In practice, teams often refer to location codes as queue lanes because routing and capacity are location-aware.
What it is: The cloud process always includes three built-in global lanes: global-1, global-2, and global-3.
Why it matters: This gives a fixed baseline of three globally available execution lanes before any regional node expansion.
What it is: Each regional node/location is a separate Uptimer.Node process hosted in that region and connected back to cloud; common deployments start with three node lanes (node-1..3), and additional node-* lanes can be added.
Why it matters: Capacity can be expanded per region without changing the core scheduler or checker pipeline.
What it is: Cloud dispatches to node queue ingress over HTTP(S) and authenticates every request with X-Uptimer-Node-Key; nodes also register and send heartbeat load data back to cloud.
Why it matters: Routing stays secure and load-aware, and failed node dispatch automatically falls back to local cloud execution.
What it is: Node processes are configured with MaxConcurrentChecks = 6 in current app settings, so each node can execute up to six checks concurrently.
Why it matters: Throughput scales predictably as additional nodes are added, while concurrency limits still protect stability.
What it is: Passwords are stored as strong, one-way cryptographic hashes with salt (never plaintext).
Why it matters: If a database is exposed, raw passwords are not recoverable from stored credential material.
What it is: Anti-forgery tokens validate that state-changing requests originate from trusted user interaction.
Why it matters: Blocks cross-site request forgery attempts that try to perform actions using an existing session.
What it is: Request throttling on sensitive endpoints and workflows to constrain abuse velocity.
Why it matters: Reduces brute-force, enumeration, and denial-of-service pressure before it impacts legitimate users.
What it is: Outbound target validation blocks private/internal destinations and unsafe redirect chains for monitor checks.
Why it matters: Prevents server-side request forgery from being used to probe internal infrastructure or metadata endpoints.
What it is: Public status endpoints are separated from tenant-admin data paths with scoped queries and explicit boundaries.
Why it matters: Ensures public pages expose only intended data while private operational records stay tenant-confidential.
What it is: Sensitive tokens and credentials are masked or omitted in logs, audit outputs, and UI surfaces.
Why it matters: Keeps observability useful without leaking secrets through diagnostic paths.
What it is: Validation and normalization of user-supplied endpoint inputs before persistence or execution.
Why it matters: Reduces injection risk, malformed target abuse, and accidental exposure of unsafe URL patterns.
| Term | Meaning | Why you should care |
|---|---|---|
P95 |
95th percentile value from repeated measurements. | Represents dependable performance instead of one-time peak results. |
API |
Application Programming Interface. | Defines how systems and automation integrate with Uptimer safely and consistently. |
CSRF |
Cross-Site Request Forgery. | A class of attacks where a browser is tricked into sending unauthorized actions. |
CSP |
Content Security Policy. | Restricts script/content execution paths to reduce XSS and injection risk. |
DSAR |
Data Subject Access Request. | Operational process for privacy requests like data access, export, and erasure actions. |
GDPR |
General Data Protection Regulation. | Defines privacy obligations that shape retention, auditability, and DSAR workflows. |
MFA |
Multi-Factor Authentication. | Adds an extra identity proof step to reduce account takeover risk. |
OIDC |
OpenID Connect. | Modern identity layer for enterprise SSO and external login federation. |
RBAC |
Role-Based Access Control. | Limits privileged actions by user role to enforce least-privilege access. |
SAML |
Security Assertion Markup Language. | Enterprise identity protocol often used for centralized workforce sign-in. |
SCIM |
System for Cross-domain Identity Management. | Automates user lifecycle provisioning and deprovisioning from identity providers. |
SLA |
Service Level Agreement. | Defines contractual reliability/response expectations and accountability targets. |
SSO |
Single Sign-On. | Lets users authenticate once with a trusted identity provider across systems. |
SSRF |
Server-Side Request Forgery. | An attack that abuses server outbound requests to reach unintended internal targets. |
TCP |
Transmission Control Protocol. | Supports port/connectivity health checks alongside HTTP endpoint checks. |
TLS |
Transport Layer Security. | Encrypts in-transit traffic and protects confidentiality/integrity between systems. |
Backpressure |
Load-control behavior that queues and slows work when demand exceeds capacity. | Prevents system collapse during spikes and preserves overall reliability. |
Blazor |
C# component framework for building interactive web UI with Razor. | Lets the product ship rich UX while keeping core logic closer to trusted server code. |
Interactive Server |
Blazor render mode where UI is server-driven and interactive after initial render. | Supports dynamic UI with central policy enforcement and reduced client attack surface. |
Minimal API |
Lightweight ASP.NET Core endpoint model using concise route handlers. | Improves maintainability and iteration speed for a large, policy-rich API surface. |
Tenant Isolation |
Data and access boundaries between customer workspaces. | Protects confidentiality and limits blast radius in multi-tenant operation. |
Retention Window |
How long operational and security records are kept before cleanup. | Defines compliance posture and storage footprint over time. |
