Instatus:只做状态页做到MRR $48K,指标全部公开——砍掉零付费客户的“Sup”,改向大企业并涨价

“出故障时,怎么通知客户?”只解决这一个问题的状态页SaaS,已经做到MRR $48,017、付费客户1,248家。Instatus把自己的经营指标放在公开页面上,任何人都能查证(2026年8月访问时点,显示5月29日更新。ARR为$576,208,总用户62,261)。

了解这款产品的前身后,数字的含义会改变。创始人Ali Salah最初做的版本叫“Sup”,一个付费客户都没有。今天的Instatus是在同一问题领域里,把名字、品牌、价格、目标客户全部换掉后的“第二圈”。不是重做产品,而是重做卖法之后才立起来——这个顺序是本案例的核心。

数字盘点

失败的原因不是产品,而是“选错了客户”

Salah的复盘中始终一致的一点,是他没有把Sup的失败归咎于功能。Sup面向初创公司打造,但创业初期的公司根本不需要状态页。客户少的时候,连“该通知谁”都没有,整理状态页的优先级低到不能再低。也就是说,他在用讨人喜欢的品牌,向一个问题并不存在的人群兜售。

转向Instatus正是针对这一诊断开出的处方。真正需要状态页的,是客户数量多、故障时的咨询会变成成本、并对SLA负有说明责任的规模型企业。于是他把目标客户挪向大企业,改成符合该群体的、显得可靠的品牌,并提高了价格。不是靠便宜扩大覆盖面,而是靠涨价只留下“问题足够切身”的那部分人——方向上与Deep Research的价格转型案例相同,都是把定价放在功能改进之前动的类型。

B2B工具在买方公司内部需要被“解释为什么要用它”。这时,轻松友好的品牌反而碍事,而稳重的名字与足够的价格更容易过关。Sup的失败说明:同样的功能,品牌与价格决定了“能通过谁的审批”，这是个不起眼却决定性的变量。

获客与“公开”这一战略

重新出发的发布是在Twitter和Product Hunt上进行的,Salah说“Twitter上的朋友们真的帮忙传开了”。他本人列举的后续增长举措是:增加功能与新设高阶套餐、与Embarque.io合作的博客内容,以及/now页面和GitHub仓库这类小型副项目群。都不算张扬,但一致地把曝光放在开发者与技术决策者会经过的地方。

经营指标的全面公开,在这个脉络里同样是曝光装置。把MRR、付费客户数乃至非营利账户数都公开的“open页面”,本身就会成为话题、被链接,并留下像本文这样可验证的记录。与在指标公开上先行的Plausible的$1M ARR一样,面向开发者的商品里,“不隐藏”同时兼任信任与营销。

增长节奏也值得记录。从2022年2月的$5K到最近的$48K,约四年10倍。按月度抹平来看,是没有夸张跳跃的、典型B2B订阅式的复利曲线。看MRR $5K时点的计划(宕机检测的Instatus Now、监控、事故管理),也能看出他是从单一功能向周边功能分阶段扩展的。

公开页面的数字还透出收入结构。总用户62,261对付费客户1,248，比例约2%,绝大多数是免费使用。即便如此MRR $48K仍能成立,是因为付费一侧的单价平均在每月$38左右(MRR÷付费客户数),明显高于免费工具的行情。“用免费扩大覆盖面,只向问题切身的人群卖高价”，转型后的设计直接体现在数字上。连面向非营利组织的免费账户有93个都披露出来,是这种公开方针彻底程度的细节。

风险与弱点

这门生意在结构上的位置是“大厂的一个功能”。状态页是Atlassian(Statuspage)这类大厂拥有同类产品、监控SaaS也可能把它作为功能内置的领域。单一功能专营的防线,依赖于那一点上的完成度与价格弹性。此外,Salah是单人创业,雇用第一位兼职工程师是在MRR增长之后。用实质上1〜2人支撑与监控、故障响应相关的基础设施型商品,在成本结构上是优势,但从可用性期待的角度看始终是一根绷紧的绳，把同样的紧张运营了十年量级的Healthchecks.io的一人SaaS就是这一类型的先例。

另外,公开的指标出自本人运营的页面,并非经过第三方审计的数字。可验证性很高,但其性质是“持续的自我申报”,这一点也需要附记。

可复制的条件与局限

可以一般化的有三点:①产品卖不动时,在重做之前先怀疑“卖给谁、卖多少钱、以什么面貌卖”;②B2B商品的价格可以设计成一道筛子,只留下问题切身的客户;③面向开发者的商品里,公开指标本身就是营销。

局限在于,Sup→Instatus的转型之所以奏效,是因为状态页这个问题在大企业侧真实存在,涨价与改名只是“发现”了那份需求。在没有需求的领域做同样的动作,结果不会改变。而且指标公开已经变成模仿成本很低的做法,如今作为差异化偏弱,也难以期待当年那样的话题性。转型的套路可以移植,但转型目的地是否有需求,每一次都得从零验证。