ups.dev

What it is

Status pages. But the components are different.

A traditional status page tracks: is the server up? Is the database responding? Is the API returning 200s? That’s fine for 2015. In 2026, the failure modes are different: a model provider goes down mid-reasoning, an agent gets stuck in a tool loop, token context limits hit at runtime, a third-party API returns 200s but with degraded quality.

ups.dev tracks those things.

What’s working

• Status pages with agent-aware component types (model provider health, agent performance, API latency)
• MCP integration — Claude Code, Cursor, and other MCP-compatible tools can read and update status programmatically
• Incident templates for AI failure modes (model timeout, reasoning loop, tool failure, context limit exceeded)
• Open-core model: the base is AGPL-3.0 on GitHub, deployed by self-hosters; the production app adds team features and the MCP layer

What’s not working

• Checkout flow isn’t wired to the UI yet — there’s no path from “I want to pay” to “I am paying”
• 0 paying customers as of June 2026
• Onboarding is rough — you can sign up, but figuring out what to do next requires patience

Open questions

• Does the agent-component framing resonate with actual users, or is it a solution in search of a problem?
• The MCP integration is the differentiated thing — is anyone actually using MCP-aware tools who would pay for this?
• Trademark risk on “ups” is real (UPS, the shipping company, is aggressive). Backup domain is ready.

Solved

• Architecture: Rails 8, open-core with a pro engine in a private engines directory. Clean separation between OSS and paid features.
• Infrastructure: deployed via Kamal on Hetzner. In production since March 2026.
• Signup flow: magic links via Resend, working end-to-end.
• GitHub OSS strategy: codenamev/ups is the public repo. Organic growth from the self-hosted community is the acquisition channel.