At a glance
| Sign-in | Email code, magic link, Google or GitHub. No passwords. |
|---|---|
| 2FA | Authenticator app (TOTP) with recovery codes; owners can require it. |
| API keys | Read or write scope, optional expiry, stored only as hashes. |
| Audit log | Security and admin actions with actor and IP, kept 400 days. |
| Webhooks | Signed per Standard Webhooks; subscriber endpoints verified by handshake. |
| Checks | Private and internal addresses blocked; user code runs in locked-down containers. |
| Hosting | EU infrastructure; AI requests routed only to providers that do not keep prompts for training. |
Signing in
There are no UpButler passwords to leak or reuse. You sign in with a one-time code or magic link sent to your email, or with your Google or GitHub account. Connected providers are listed in your security settings, where you can disconnect them.
Every sign-in method ends in the same place: if you have two-factor authentication on, you get a short-lived pending token (valid for 10 minutes, at most 5 attempts) and must enter a code before a session is created. Sign-in endpoints are rate limited. Step-by-step setup for everything on this page is in the security docs.
Two-factor authentication
- Use any authenticator app (TOTP): scan the QR code, confirm with a code, and you get 10 single-use recovery codes. You can replace them at any time; old ones stop working.
- Authenticator secrets are encrypted at rest and recovery codes are stored only as hashes.
- Each code can be used once: a replayed code from the same time window is rejected.
Require 2FA for the whole workspace
Workspace owners can require two-factor for every member. The owner has to turn it on for themselves first, and members without 2FA cannot use the workspace until they set it up. While you belong to a workspace that requires it, you cannot switch your own 2FA off.
Sessions
A session lasts up to 30 days. The cookie is HttpOnly, SameSite=Lax and Secure, and we store only a SHA-256 hash of its value, so a database leak would not hand out working sessions. Your security settings list your active sessions; sign out any one of them, or every session except the current one. Dashboard writes are accepted from the same origin only.
API keys and agents
- Keys have a read or read and write scope. Give dashboards and reporting tools read-only keys.
- Keys can expire automatically after 1 to 3,650 days.
- The secret is shown once and stored only as a hash. Only owners and admins can create keys.
- Give each agent its own key with an agent name: its actions are attributed to it in incident timelines and in the audit log.
- The MCP server uses the same keys and the same permission checks as the REST API.
Workspaces created by agents without a human (POST /api/v1/agent/bootstrap) are rate limited per IP, cannot send email until a human claims them, and are deleted after 7 days if nobody does.
Audit log
Sign-ins, two-factor changes, API key creation and revocation, member and role changes, billing changes, deletions and custom domain changes are recorded with who did it (a person, an agent key or the system), when, and from which IP address. Entries are kept for 400 days. Owners and admins can read and filter the log in the dashboard or through GET /api/v1/audit.
Signed webhooks
Every outgoing webhook, to your alert channels and to status page subscribers, carries webhook-id, webhook-timestamp and webhook-signature headers per the Standard Webhooks spec, so you can verify it with their libraries and reject replays. Before a status page sends updates to a subscriber's webhook, the endpoint has to echo a random challenge, which proves the subscriber controls it. Webhooks are never sent to private or internal addresses.
Safe checks
A monitoring service makes requests to addresses its users choose, which makes it a tempting tool for reaching places it should not. UpButler resolves every target before it connects and refuses anything that is not a public address:
- HTTP and manifest checks accept only
httpandhttpsURLs. - Loopback, private (RFC 1918), carrier-grade NAT, link-local (including cloud metadata endpoints), benchmarking, multicast and reserved IPv4 ranges are blocked, as are IPv6 loopback, unique-local and link-local addresses and IPv4-mapped IPv6.
- The same rules apply to TCP and DNS checks, outgoing webhooks and the Statuspage importer.
Our acceptable use rules forbid monitoring systems you are not authorized to check and using checks for load testing or attacks.
Script and browser sandbox
Script checks (Pro and Business) and real-browser checks (Business) run code you write. That code never runs in our application process. Each run gets a fresh Docker container with:
- no access to the host's environment variables or secrets;
- a read-only filesystem and all Linux capabilities dropped;
- memory, CPU and process limits (256 MB for scripts, 768 MB for browsers);
- an egress guard inside the container that blocks loopback, private, link-local and other internal addresses, so a script cannot reach the infrastructure it runs on;
- a hard kill if it runs more than 10 seconds past its timeout.
Check regions
Monitors can be checked from several EU locations at once (Helsinki, Nuremberg, Falkenstein and Lauterbourg). Remote probes have no database access: they talk to UpButler over HTTPS only, authenticated with a per-region token. A probe that stops reporting is left out of the vote instead of being counted as a failure, so a problem on our side cannot mark your service down.
Hosting and data
UpButler is operated by HootCodes LTD, an EU company, and runs on EU-based infrastructure. Data is encrypted in transit. AI features send only incident and check context to models through OpenRouter, routed only to providers that do not collect prompts for training; account details and subscriber lists are never sent. Payments are handled by Polar as merchant of record, so we never see card numbers.
What we store, the sub-processors we use, how long we keep data and your rights are in the privacy policy.
Reporting a vulnerability
If you think you have found a security issue in UpButler, email [email protected] with a description, the steps to reproduce it and the impact you expect. Please give us a reasonable chance to fix it before telling anyone else.
While testing, please:
- use your own accounts and workspaces, and never access or change other people's data;
- do not run denial-of-service tests, send spam, or use UpButler checks against systems you do not own;
- stop and tell us as soon as you reach data that is not yours.
We will not pursue legal action against researchers who act in good faith and follow these rules. We read every report, will keep you informed while we fix it, and are happy to credit you once the fix is out.