Instatus、ステータスページ一本でMRR $48K。有料顧客ゼロの「Sup」を捨てて大企業向けに値上げ

「障害が起きたとき、顧客にどう知らせるか」。この一点だけを解決するステータスページを売るSaaSが、MRR $48,017・有料顧客1,248社まで伸びている。Instatusは自社の経営指標を公開ページで開示しており、この数字は誰でも確認できる(2026年8月閲覧時点、5月29日更新表示。ARRは$576,208、総ユーザーは62,261)。

このプロダクトの前身を知ると、数字の意味が変わる。創業者のAli Salah氏が最初に作ったバージョンは「Sup」という名前で、有料顧客が一人も付かなかった。現在のInstatusは、同じ課題領域で名前・ブランド・価格・想定顧客をすべて置き直した「2周目」である。プロダクトを作り直すのではなく、売り方を作り直したら立ち上がった——この順序が、本事例の中心にある。

数字の整理

失敗の原因はプロダクトではなく「客の選び方」だった

Salah氏の振り返りで一貫しているのは、Supの失敗を機能のせいにしていないことだ。Supはスタートアップ向けに作られたが、創業初期の会社はそもそもステータスページを必要としていなかった。顧客が少なければ障害を「知らせる相手」がおらず、ページを整える優先度は限りなく低い。課題が実在しない層に、感じのいいブランドで売っていたわけだ。

Instatusへの転換は、この診断への処方箋になっている。ステータスページを本当に必要とするのは、顧客数が多く、障害時の問い合わせがコストになり、SLAへの説明責任を負う規模の企業だ。だから想定顧客を大企業側へずらし、その層に合う信頼感のあるブランドへ改め、価格も引き上げた。安くして裾野を広げるのではなく、高くして「課題が切実な層」だけに絞る。方向としては、Deep Researchの価格転換の事例と同じく、値付けを機能改善より先に動かした型である。

B2Bの道具は、買い手の社内で「これを使う理由」を説明される。そのとき、気さくなブランドは説明の邪魔になり、堅い名前と十分な価格はむしろ通りやすさになる。Supの失敗が示すのは、同じ機能でもブランドと価格が「誰の稟議を通れるか」を決めるという、地味だが決定的な変数だ。

集客と「公開する」という戦略

再出発のローンチはTwitterとProduct Huntで行われ、Salah氏は「Twitterのフレンドたちが本当に広めてくれた」と語っている。その後の成長施策として本人が挙げるのは、機能追加と上位プランの新設、Embarque.ioと組んだブログコンテンツ、そして/nowページやGitHubリポジトリのような小さなサイドプロジェクト群だ。どれも派手さはないが、開発者・技術系の意思決定者が通る場所に露出を置く施策で一貫している。

経営指標の全公開も、この文脈では露出装置として働く。MRRから有料顧客数、非営利アカウント数までを公開する「オープンページ」は、それ自体が話題になり、リンクされ、本記事のような検証可能な記録を残す。指標公開で先行したPlausibleの$1M ARRと同様、開発者向け商材では「隠さないこと」が信頼とマーケティングを兼ねる。

成長のペースも記録しておく価値がある。2022年2月の$5Kから直近の$48Kまで、およそ4年で10倍。月次で均せば派手な跳ねのない、B2Bサブスクらしい複利の曲線だ。MRR $5K時点の計画(ダウン検知のInstatus Now、監視、インシデント管理)を見ると、単機能から周辺機能への拡張を段階的に進めてきたことも分かる。

公開ページの数字は、収益の構造も透かして見せる。総ユーザー62,261に対して有料顧客は1,248。比率にして約2%で、大半は無料利用だ。それでもMRR $48Kが成り立つのは、有料側の単価が平均で月$38前後(MRR÷有料顧客数)と、無料ツールの相場より明確に高いからで、「無料で裾野を広げ、切実な層にだけ高く売る」という転換後の設計がそのまま数字に出ている。非営利団体向けの無償アカウントが93あることまで開示されているのは、この公開方針の徹底ぶりを示す細部だ。

リスクと弱点

この事業の構造的な位置は「大手の一機能」である。ステータスページはAtlassian(Statuspage)のような大手が同種製品を持ち、監視SaaSが機能の一部として同梱することもある領域だ。単機能専業の防御は、その一点での完成度と価格弾力に依存する。また、Salah氏はソロ創業で、初のパートタイムエンジニアを雇ったのはMRRが伸びてからだ。監視や障害対応に関わるインフラ的な商材を実質1〜2人で支える体制は、コスト構造としては強みだが、可用性への期待という点では常に張り詰めた綱でもある。同じ緊張を10年単位で運用してきたHealthchecks.ioの一人SaaSが、この型の先行例だ。

なお、公開メトリクスは本人運営のページであり、第三者監査を経た数字ではない。検証可能性は高いが、その性質は「継続的な自己申告」である点も付記しておく。

再現の条件と限界

この転換劇から持ち出せるのは、①プロダクトが売れないとき、作り直す前に「誰に・いくらで・どんな顔で」売っているかを疑う、②B2B商材の価格は、課題が切実な層だけを残すフィルタとして設計できる、③開発者向け商材では指標の公開自体がマーケティングになる、の3点だ。

限界としては、Sup→Instatusの転換が効いたのは、ステータスページという課題が大企業側に実在したからで、値上げと改名はその需要を「発見」しただけだ。需要のない領域で同じ操作をしても結果は変わらない。また、指標公開は模倣コストの低い施策になったため、いまや差別化としては弱く、当時ほどの話題性は期待できない。転換の型は移植できるが、転換先に需要があるかの検証は、毎回ゼロからやり直しになる。