# Our plans in 2025

Dec 31, 2024 | by [Maximilian Kaske](https://x.com/mxkaske) | [company]

This post has two purposes: (a) _sharing our vision with you_ and (b) _holding ourselves accountable_.

We know that startup cycles are unpredictable and move fast. This post will serve as a checkpoint—allowing us to reflect on what we’ve achieved and where we may have lost sight of our initial plan.

After all the work, we’ve finally distilled our focus into three main pillars:

1. **Synthetic Monitoring**
2. **Status Pages**
3. **Alerting**

Additionally, **Community Editions** are something we’d like to invest in, enabling faster access to self-hosted solutions.

Let’s explore these pillars and uncover our key drivers for 2025.

* * *

### 1. Synthetic Monitoring

This is where our heart lies.

We are committed to providing the best tools to monitor your APIs, websites and server globally. So far, we’ve built a highly performant checker that you can deploy as your own probe.

Moving forward, we want to embrace standards **OpenTelemetry.**

We believe the current synthetic monitoring ecosystem is broken; you cannot build an observability tool isolated from the rest of the observability stack.

What does this mean? By leveraging OpenTelemetry, we can export data from our probes via metrics to your observability stacks.

This flexibility allows you to choose how you handle the data—leaving alerts, visualizations, and storage to your stack while enabling custom integrations.

Besides, we also think of a new kind of monitor which is neither TCP nor HTTP based but based on metrics from your system. You define a PromQL query and configure custom assertions; if an assertion fails, you can inform your users via a _headless_ status page and receive alerts instantly.

But there’s more. As developers, we live in our IDEs and terminals. That’s why we really want to improve our **openstatus CLI** and `config.openstatus.yaml` to make developer experience neat (DX). Allowing you to run your synthetic check in your CI workflow or from your terminal.

Thinking of DX, if interest exists, we’d start building SDKs for your favorite language.

Some of you also love a beautifully crafted UI; this is why we want to make the dashboard feel _alive_—showing real-time pings as they await responses.

Looking ahead, we want to expand our probes to more cloud providers like AWS, GCP, Koyeb, Render, or more if requested.

* * *

### 2. Status Pages

Status pages go hand in hand with synthetic monitoring.

We aim to make it effortless to communicate incidents to your users while ensuring the page feels uniquely _yours_. **Customization is key**: supporting brand colors, layouts, and enabling custom `script` injections (e.g., for tools like Plausible to learn who your users are and where they’re coming from).

As we work on our otel monitor, integrating non-http/tcp monitors will be possible, allowing you to show any part of your stack without the need to define a health endpoint.

* * *

### 3. Alerting

Let’s clarify what _our_ Alerting is. It’s **not on-call rotation**—instead, it’s about sending notifications to your preferred channels when something unexpected happens. Whether it’s failures, degraded performance, or endpoint recoveries, you’ll always be informed and ready to act.

So far, our alerting configurations have been basic. We plan to make them more customizable by **reworking our Alert Engine**. Features we’re considering include:

- Retry policies
- Delays (e.g., “wait X minutes before sending a notification”)
- Recovery policies (e.g. “wait for X successful pings”)

Naturally, we’ll integrate with more notification channels and third-party tools for on-call rotations and incident management. While we’ll provide the basics, our focus will remain on flexibility and core alerting—not full-blown incident management. We’ll leave that part to others.

* * *

### Community Editions

Last but not least, we know many of you want easy-to-host solutions to monitor your services. However, hosting our full application currently involves third-party dependencies and some setup complexity. Instead, we’ll focus on:

(a) _Supporting the community_ as they build on top of OpenStatus core infra.

(b) _Building smaller, easily self-hostable solutions_ (e.g., [vercel-edge-ping](https://github.com/openstatusHQ/vercel-edge-ping)).

You should think of our community editions as Uptime Kuma on steroids with powerful opentelemetry support based on our work for our main product.

We aren't making the full app difficult to host on purpose. Instead, we're focusing on keeping things simple while meeting community needs. As enterprises request specific features like dedicated databases and queues, we'll evolve toward a more modular architecture.

* * *

### Recap

Here are the key focus areas for each pillar in 2025:

- **Synthetic Monitoring**: OTel adoption and developer experience (CLI, SDK, real-time UX).
- **Status Pages**: Customization (styles, scripts) and third-party integrations.
- **Alerting**: Advanced configurations and more integrations.
- **Community Editions**: Smaller, self-hostable projects.

If there’s something crucial you’re looking for, we’d love to hear from you. Join our [Discord](/content/discord/index.html) or drop us a [message](mailto:ping@openstatus.dev)!

Thanks for supporting us on this journey. ❤️

**Happy New Year,**

Thibault and Max