Cronitor：两位创始人十二年独立经营，把监控按「监控数 × 席位」计价

直接结论

Cronitor 的定价页上有一句话，把这篇案例的重点说完了：

No base fee or minimum — pay only for the monitors and users you use.

它收的是监控数和席位。这两个量既是客户的用量，也几乎就是服务方最直接的资源消耗量——每多一个被监控对象，就多一份需要按时执行的检查与需要保存的历史。官方账单示例写得很直白：20 monitors × $2/mo = $40 + 3 users × $5/mo = $15 = $55/mo，billed monthly, no contract。

第二件值得看的是谁在做。官方 About 页的 FOUNDERS 段在 2026 年仍并列两位署名：August Flanagan 与 Shane Harter，两人都写「Co-Founder」；正文以第一人称复数叙述并署「August & Shane Founders」。而起源在同一页上写得很具体：「Cronitor started in March 2014 with a text message.」——从 2014 年 3 月到本文访问日 2026 年 9 月已十二年（页面自身的措辞是「Ten years later」与「Over a decade in」，本文的十二年是按官方给出的年月与访问日计算的，页面没有给出年数）。

先把边界划清楚：收入、MRR、成本、利润率、客户数与员工人数都没有公开。官方关于独立经营只有一句自述——「We’ve stayed independent, grown with our community, and kept building tools we use ourselves every day.」这句话只证明独立经营：页面既没提融资，也没提被收购，所以本文不会写成「从未融资」或「拒绝被收购」。另外官方两个页面自报的开发者数量并不一致（About 页写「over 70,000 developers」，Customers 页写「100,000+ developers」），本文两个都照录，不取其一当作事实。

证据状态

• 当前公开事实（本轮逐字核对）：定价页三档结构与全部费率、账单演算示例、「no commitments — switch plans or cancel anytime」；About 页的定位句、五项监控工具列表、FOUNDERS 段两位署名、2014 年 3 月起源与 2014–2026 功能时间线；文档页的 MCP server 端点与「control plane」定位。
• 公司自述（未经独立审计）：「over 70,000 developers」「100,000+ developers」「99.997% UPTIME LAST 12 MONTHS」「100M+ EVENTS PER DAY」「10K+ ALERTS PER DAY」「2014 FOUNDED IN CALIFORNIA」，以及时间线里把 2026 年那一项自报为「MCP server and AI agent monitoring」。
• 来源内部不一致（如实记录，不作调和）：同一域名、同一访问日的两个页面给出的开发者数量不同（70,000+ 与 100,000+）。本文不推断哪个更准，也不把任一数字当作经营结论。
• 编辑判断：「计费单位等于成本单位」是本文对公开定价结构的分析，不是官方给出的因果结论；免费档成本有界（5 monitors 上限）同样是本文的解读。
• 未公开：收入、MRR、成本、利润率、客户数、员工数、两位创始人的分工与工时、内部 AI 使用情况、接入 MCP 的客户比例。

谁在做、做的是什么

About 页把产品定义写成一句给开发者看的话：「Cronitor builds monitoring tools for developers who care about reliability. When something breaks, we tell you fast with the context needed to fix it.」

范围则是五个监控工具合到一个平台——官方列出的五项是 cron job monitoring、website and API monitoring、heartbeat monitoring、website analytics and real user monitoring、hosted status pages。它不是「一个监控功能的五种叫法」，而是从「定时任务有没有按时跑」这一个问题出发，逐年长出可用性、心跳、前端性能与对外沟通（状态页）。

起源故事罕见到可以直接当案例读：August 在一家物流创业公司做创始工程师时，一个关键 cron 任务静默失败，他给 Shane 发短信问「How do you monitor your cron jobs at work?」——而 Shane 当时在一家「multi-billion dollar company」，答案是他们也没监控。官方原文写：

We compared notes, looked at what was available, and realized nobody had built something simple that just worked. So we decided to build it ourselves.

几个月后产品在 Hacker News 发布。这里要分清：Hacker News 发布属一次性事件，官方用它说明「we weren’t the only ones with this problem」，但它不是可复制的获客渠道。

功能时间线也值得照抄，因为它展示了「独立团队如何控制范围」：2014 基础 cron 监控 → 2016 可用性监控 → 2017 CronitorCLI → 2019 浏览器合成监控 → 2020 Kubernetes 集成 → 2022 状态页 → 2023 网站分析与 RUM → 2025 Cron Dashboard → 2026 MCP server and AI agent monitoring。十二年里带年份的节点共九项，平均一年多才一项。

定价结构：把客户的用量当作计费单位

定价页顶部说明：「The Business plan starts with a 14 day free trial — then pay monthly based on your actual usage.」三档如下：

档位	价格（官方原文）	关键差异
Hacker	$0 free forever	5 monitors、Email and Slack alerts、基本状态页；无 SMS 告警与高级集成；最快检查频率 5 分钟
Business	$2 /mo per monitor + $5 /mo per user	14 天免费试用后按实际用量计费；11 个告警集成、SMS 与值班告警、12 个月数据保留、不限 API 请求、SAML SSO（+$5/mo per user）、按量折扣、邮件与聊天支持；最快检查频率 30 秒
Enterprise	from $6,000 /yr（annual invoice billing）	定制功能与集成、专属工程师、优先支持、灵活开票

按量部分被拆得很细，新能力各自挂独立费率，而不是靠整体涨价：Web Analytics and Errors 在 Hacker 档含 100,000 events free、Business 档 $10/mo per 100,000 events；合成浏览器检查 $1/mo per 1,000 checks；品牌化状态页 $25/mo per page、私有状态页 $50/mo per page。状态页包含的订阅者名额也分档：50 / 500 / Unlimited。

三个可复制的细节：

第一，免费档写的是硬上限，不是「合理使用」。 Hacker 档写死 5 monitors、1 个状态页、1 个 dashboard user、5 分钟最快检查频率。对一门按量计费的生意来说，这等于把免费用户的成本提前封顶——免费层的规模不会随着口碑传播无限膨胀成运维账单。

第二，转化前先把账单算给客户看。 定价页有一段专门演算：20 monitors × $2 = $40，加上 3 users × $5 = $15，得到「YOUR BILL $55/mo, billed monthly, no contract」。按量计费最常见的阻力是「我不知道最后会付多少」，这里用一次具体演算解决，而不是用「灵活」这类形容词。

第三，用「随时可退」替代年付绑定。 Business 档的说明是「no commitments — switch plans or cancel anytime」，账单示例也写「no contract」。代价是现金流少了年付预收的确定性，收益是自助开通路径上少了一道需要人工解释的门槛——对一个只有两位创始人、没有销售团队的团队来说，这个交换是合理的。

为什么「无底价 + 免费档封顶」对独立经营者成立

这一节是编辑判断，不是官方结论。

无底价意味着小客户不亏钱：一个只用 2 个监控的客户付 $4/月，服务方的资源消耗也大致对应这两个监控，不存在「维护一个付 $4 的客户却要摊一份固定成本」的倒挂。而免费档封顶 5 个监控，意味着免费用户的存量成本也是有界的。

这套结构真正的前提是产品的单位成本随用量线性变化。如果每个监控背后都需要人工介入（例如逐个为客户配置、排障、解释告警），按量计费会把支持成本变成不可预测的负债，而不是随收入增长的变量。Cronitor 在这一层的自动化程度究竟如何、两位创始人每周投入多少小时、支持量有多大，官方都没有公开，因此本文不把它写成「两人就能轻松支撑十万开发者」的故事。

更诚实的一点是：官方把「支持」明确写进了收费档位——Business 档「Email and chat support」、Enterprise 档「Dedicated engineer」「Priority support」。也就是说，人际工作并没有被计费结构消除，只是被限定在了付得起的那一档。

AI 与 agent 出现的位置：双向，但都是控制面

这是本条案例少见的、有官方一手证据的 AI 相关点，但要看清它到底是什么。

方向一：让 agent 管理 Cronitor。 官方文档页写明 Cronitor MCP server 的作用是「lets compatible clients create and manage resources in your Cronitor account」，端点为 https://cronitor.io/mcp，定位是「a control plane for inspecting and managing Cronitor resources」。文档同时把边界说得很清楚——它不是运行时探针：「It does not replace runtime instrumentation: jobs and heartbeats must send telemetry from the workload’s real execution path through CronitorCLI, an SDK, or the Telemetry API.」并建议「Start with read-only summary tools」，还提醒事件消息、命令输出、请求头等可能含客户数据或密钥，需要时才展开字段。

官方 llms.txt 则把这条路径写成了面向 agent 的自我介绍：「Agents manage it through the Cronitor MCP server at https://cronitor.io/mcp, CronitorCLI, or the REST API.」，并给出 skill 安装命令 npx skills add cronitorio/agent-skills。

方向二：把 MCP server 当作被监控对象。 官方指南页写：「Cronitor uptime checks can monitor a network-accessible Model Context Protocol (MCP) server by sending a safe JSON-RPC request and asserting on the response.」它探测的是协议路由、授权中间件与工具列表端点是否响应；文档也注明无法探测 stdio 型 MCP server，那种情况要改用心跳或作业监控来盯着启动进程。

把两者合起来看，AI 在这里的位置是运维接口，不是产品价值本身：agent 可以更快地批量巡检与调整监控配置，但「什么该被监控」「阈值定多少」「告警来了谁负责」仍然在人的一侧。至于这个方法在多大程度上真的减少了他们自己的运营工作、有多少客户在用 MCP、相关的成本与收入占比——全部未公开，无法独立核实。也正因为没有证据，本文不给这条案例贴 automation-operations 标签。

可复制的部分

1. 让计费单位等于成本单位。 客户多用一份，你多花一份；写「no base fee or minimum」才站得住。
2. 免费档给硬上限。 把 monitor 数、席位、检查频率都写死，免费层的成本就不会随传播失控。
3. 在定价页演算一次真实账单。 用一组具体数字（20 monitors + 3 users = $55/mo）替代「灵活计费」这类说辞，把疑虑在转化前消掉。
4. 新能力挂独立费率，不动老结构。 状态页、合成检查、RUM 事件各自定价，已付费客户的价格认知不被新产品打乱。
5. 把支持写进档位，而不是假装它不存在。 邮件与聊天支持放 Business、专属工程师放 Enterprise，让「需要人的部分」有明确的价格对应。
6. 按年增加范围。 十二年九个带年份的功能节点，是一条可以照着走的节奏，而不是必须一次铺满的清单。

不可复制的部分

十二年连续经营沉淀出的基础设施与可靠性口碑无法压缩。官方自报的「99.997% UPTIME LAST 12 MONTHS」与「100M+ EVENTS PER DAY」未经本文独立审计，但它们指向的容量与运维经验只能靠时间积累。

2014 年在 Hacker News 发布并因此确认需求，是一次性事件。那一天的社区时机、当时的竞品空白——官方原文是「nobody had built something simple that just worked」——都不再存在；类似的发布现在可能毫无水花。

更关键的是经济模型仍不可验证：收入、MRR、成本、利润率、客户数、员工数全部未公开，只有定价结构可见。因此任何人都不应把本文的定价拆解当成「这样定价就成立」的证明——它只说明这家公司选择了这套结构，而不是这套结构保证了结果。

最后，官方页面对「独立」的表述只有「stayed independent」一句，不能被扩写成「从未融资」「拒绝收购」或任何关于资本选择的结论。这一层证据就是缺的，本文不补。

AOPC 适配判断

Cronitor 与一人公司/AOPC 相关的部分，是定价结构如何让少量人力承接分层客户：无底价的按量订阅让小客户不必被人力摊薄，免费档用硬上限控制存量成本，账单演算把自助转化路上的解释成本降到最低，支持则被明确放进付费档位。这些都是一个人或两个人可以照着设计的经营结构。

但必须同时说清不适配之处：这不是一人公司案例。官方 About 页在 2026 年仍并列两位联合创始人，且十二年经营、百万级事件量的基础设施与可靠性口碑都不是新项目能复制的资产。它是两位创始人主导的独立经营团队的参考样本——适合用来对照「计费单位怎么定、免费档怎么设边界、支持怎么定价」，不适合用来推断「两个人就能做到这个规模」。

来源

• Cronitor：About Us核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于核查 FOUNDERS 段两位联合创始人署名、2014 年 3 月起源故事、五项监控工具列表、2014–2026 功能时间线，以及「stayed independent」与「over 70,000 developers」两处自述。
• Cronitor：Simple Pricing核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于逐档抄录 Hacker/Business/Enterprise 价格与限制、账单演算示例、「No base fee or minimum」与「no commitments」原文，以及状态页、合成检查与 RUM 事件的独立费率。
• Cronitor：Customers核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于记录「100,000+ developers」与「99.997% UPTIME LAST 12 MONTHS」「100M+ EVENTS PER DAY」「2014 FOUNDED IN CALIFORNIA」等公司自报数字，以及与 About 页开发者数量不一致这一事实。
• Cronitor：Connect an MCP Client to Cronitor核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于核查 MCP server 端点、控制面定位、「不属于运行时探针」的边界说明与只读工具建议。
• Cronitor：llms.txt核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于核查面向 AI agent 的产品自述原文与 agent skill 安装命令。
• Cronitor：Monitor an MCP Server核查于 2026/9/27，访问于 2026 年 9 月 27 日；用于核查「用 JSON-RPC tools/list 探测 MCP server」这一被监控对象用法与 stdio 型 server 的例外说明。

截图仅用于呈现访问日无需登录的官方公开页面，不证明收入、用户结果、合作或背书。本文的定价解读与「计费单位等于成本单位」属编辑判断，不构成经营、法律或合规建议。