openstatus.dev
Openstatus
www.openstatus.dev
add 2026 blog post (#1587)
* add 2026 blog post
* add image
* improve post
* add small things
* small typo
* more typo
authored by
Thibault Le Ouay
and committed by
GitHub
b41404b5
1897e676
+139
-1
+1
-1
apps/web/next-env.d.ts
+1
-1
apps/web/next-env.d.ts
···
1
1
/// <reference types="next" />
2
2
/// <reference types="next/image-types/global" />
3
-
import "./.next/types/routes.d.ts";
3
+
import "./.next/dev/types/routes.d.ts";
4
4
5
5
// NOTE: This file should not be edited
6
6
// see https://nextjs.org/docs/app/api-reference/config/typescript for more information.
apps/web/public/assets/posts/2026-roadmap/2026.png
apps/web/public/assets/posts/2026-roadmap/2026.png
This is a binary file and will not be displayed.
apps/web/public/assets/posts/2026-roadmap/linear.png
apps/web/public/assets/posts/2026-roadmap/linear.png
This is a binary file and will not be displayed.
apps/web/public/assets/posts/2026-roadmap/team-retreat.jpg
apps/web/public/assets/posts/2026-roadmap/team-retreat.jpg
This is a binary file and will not be displayed.
+138
apps/web/src/content/pages/blog/2026-roadmap.mdx
+138
apps/web/src/content/pages/blog/2026-roadmap.mdx
···
1
+
---
2
+
title: "Openstatus 2025 Year in Review: Lessons Learned and What’s Next"
3
+
description: "As we close out 2025, it’s the perfect time to pause, reflect, and share where we are heading for 2026."
4
+
author: "Thibault Le Ouay Ducasse"
5
+
publishedAt: "2025-12-1"
6
+
image: "/assets/posts/2026-roadmap/2026.png"
7
+
category: "company"
8
+
---
9
+
10
+
As we close out 2025, it’s the perfect time to pause, reflect, and share where we are heading. It has been a year of shipping, learning, and making hard decisions about the future of OpenStatus.
11
+
12
+
Before we dive into our roadmap for 2026, let’s look at what we accomplished together this year.
13
+
14
+
## 2025 Retrospective
15
+
16
+
### A Year of Shipping
17
+
18
+
If you look back at our [2025 roadmap](/blog/vision-2025), our goal was clear: focus on synthetic monitoring, status pages, alerting, and self-hosting.
19
+
20
+
Here are some of the [highlights](/changelog) from the past 12 months:
21
+
- **DNS Monitor:** We added the ability to track DNS records giving you visibility into the fundamental plumbing of your connectivity.
22
+
- **Multi-Cloud Deployment:** We enabled monitoring from different cloud providers to help you visualize how network routing affects your latency globally.
23
+
- **Private location**: We launched the ability to monitor internal services from within your own infrastructure.
24
+
- **Theme Builder:** We gave you complete control over the look and feel of your status pages to fully match your brand identity.
25
+
- **New Status Page:** A completely redesigned, faster, and accessible public face for your uptime.
26
+
- **New Dashboard:** A cleaner UI designed to visualize your data without the noise.
27
+
- **New Marketing Page:** A fresh style and clearer positioning.
28
+
- **Self-Hosting:** We released a [self-hosted version](https://docs.openstatus.dev/guides/self-hosting-openstatus/) of openstatus.
29
+
30
+
<Image
31
+
alt="Linear issue created more than a year ago, splitting the apps into multiple apps"
32
+
src="/assets/posts/2026-roadmap/linear.png"
33
+
width={690}
34
+
height={558}
35
+
/>
36
+
37
+
**A Note on Architecture:**
38
+
We also spent significant time under the hood. We’ve decoupled our applications, making the platform faster to build and easier for the community to contribute to. This refactor was on our wishlist for over a year, and we are thrilled to see it finally come to life.
39
+
40
+
41
+
### Staying bootstrap
42
+
43
+
Transparency is one of our core values. In the spirit of that transparency: **In 2025, we went through an acquisition process.**
44
+
45
+
The offer was strong, and the acquiring team was fantastic. It would have been a "good exit." However, as we moved through the due diligence, we realized something profound: **we aren't done yet**.
46
+
47
+
We felt that selling now would leave too much value on the table, not just financially, but in terms of the product vision we want to deliver to the OpenStatus community. We still have the strength, motivation, and resources to push OpenStatus further on our own terms.
48
+
49
+
We chose to stay independent. We chose to keep building.
50
+
51
+
52
+
### The first openstatus retreat
53
+
54
+
<Image
55
+
alt="Us in Kochel am See for the openstatus 2025 team retreat"
56
+
src="/assets/posts/2026-roadmap/team-retreat.jpg"
57
+
width={608}
58
+
height={456}
59
+
/>
60
+
61
+
2025 wasn't just about code; it was about us. We held our very first team retreat. We looked for a location that was equidistant for us, easy to access, and emphatically _not_ Paris.
62
+
63
+
We chose **Munich**.
64
+
65
+
We spent the week in Kochel am See, eating Kaiserschmarrn, riding e-bikes, and drinking Bavarian beer. It was a vital reminder that while we build software, the human connection is what keeps the momentum alive.
66
+
67
+
68
+
## Lessons learned: Let's go "Status Page First"
69
+
70
+
Building a SaaS is a constant loop of shipping and listening. In 2025, thanks to the help of Alex and Emily shaping our perspective, we learned two massive lessons about our market fit.
71
+
72
+
We used to try to be "mild"—trying to look approachable for everyone. But the reality is: **our users are engineers.** We need to own that niche.
73
+
74
+
### The Enterprise Dilemma
75
+
76
+
We realized that trying to be an "all-in-one" uptime monitoring solution for Enterprise is the wrong play.
77
+
- **The Reality:** Enterprises already have established monitoring stacks (Datadog, Prometheus, etc.).
78
+
- **The Friction:** They generally _don't_ want a status page tightly coupled to raw monitoring data. There are internal politics involved in declaring incidents; they need a curated status report, not a raw feed of 500 errors.
79
+
- **The Fit**: Paradoxically, we are often "too cheap" for Enterprise, and our complex multi-cloud monitoring is overkill for anyone not doing $1B in revenue.
80
+
81
+
### The Solo-Dev/Hobbyist Pattern
82
+
83
+
On the other end of the spectrum, solo developers love our bundled uptime monitoring, status page and the fact that we are open source. However, while usage in this segment is high, it rarely converts to sustainable revenue.
84
+
85
+
We have finally released our self-hosted version to better serve this community. We want hobbyists and solo devs to have access to reliable uptime monitoring without the pressure of a SaaS subscription.
86
+
87
+
### The Aha! Moment
88
+
89
+
By analyzing our user journey, we found a distinct pattern:
90
+
91
+
> Users search for a Status Page → They see it's Open Source → They stay for the bundled Uptime Monitoring.
92
+
93
+
The entry point isn't the monitoring; **it's the Status Page.**
94
+
95
+
96
+
## The Plan for 2026: Doubling Down on the Status Page
97
+
98
+
We’ve spent the last year listening, learning, and watching how you handle downtime. If there is one universal truth we’ve uncovered, it’s this:
99
+
100
+
**Context switching is the enemy of incident resolution.**
101
+
102
+
When your database locks up or your API starts returning 500s, the last thing you want to do is tab out of your terminal, to log into a separate dashboard just to update a status page. It breaks your flow when you need it most.
103
+
104
+
#### **Our Goal for 2026**
105
+
106
+
Based on these learnings, we are setting an ambitious goal for 2026: **To build the absolute best tooling for Status Pages on the market.**
107
+
108
+
But how do we define "best"?
109
+
110
+
To us, the best tool is the one that gets out of your way. It’s a tool that lives inside your existing workflow. We believe you should be able to manage the communication of an incident from the exact same place you are fixing it.
111
+
112
+
#### **The Philosophy: "Stripe for Incidents"**
113
+
114
+
We realized that every engineering team has a unique DNA. A three-person startup handles fires differently than a 50-person scale-up. Because of this, we are moving away from the "one-size-fits-all" approach.
115
+
116
+
Instead of imposing a rigid workflow on you, we want to provide the **primitives** that allow you to build your own.
117
+
118
+
We aim to become the **"Stripe for Incidents"** an infrastructure platform that is so flexible and developer-friendly that you can build your ideal incident management process right on top of us.
119
+
120
+
#### **The Roadmap: API-First and ChatOps**
121
+
122
+
To make this a reality, our 2026 roadmap is focused on meeting you where you work:
123
+
124
+
- **Deep ChatOps Integration:** We are building robust **Slack and Discord apps**. You should be able to declare an incident, update a component, and notify customers without ever leaving your team's chat channel.
125
+
126
+
- **API-First Expansion:** We are drastically improving our API. We want you to be able to script updates, automate status changes via webhooks from your monitoring tools, and integrate us deeply into your CI/CD or observability stack.
127
+
128
+
129
+
**Focusing on the Builders** We believe our product currently shines brightest for **small teams and startups**. In 2026, we are doubling down on you. We want to give you the lean, powerful tools you need to maintain trust with your users without the enterprise bloat.
130
+
131
+
**Looking Ahead: Moving Upstream** Status pages are just the beginning. Currently, we help you communicate _during_ the fire. As our tooling matures, we plan to move "upstream" in your workflow.
132
+
133
+
Once our status page tooling is perfected, we will expand toward full **Incident Management**. We want to bridge the gap between _detecting_ the problem and _communicating_ it, eventually helping you manage the entire lifecycle of an incident.
134
+
135
+
136
+
Looking forward to next year.
137
+
138
+
Cheers, Thibault and Max