openstatus.dev
Openstatus
www.openstatus.dev
chore: introduction page components blog post (#1799)
* chore: clean up
* chore: clean up
* chore: more clean up
* refactor: external to static page component type
* fix: tsc
* fix: sync
* chore: form-components
* refactor: move configuration to page components
* fix: nullable
* fix: tsc
* chore: constraint db migration
* chore: events
* chore: third-party
* chore: add warning on component removal
* chore: add docs
* chore: remove migration note
* chore: introduction page components blog post
* fix: tsc
* chore: add pricing section
authored by
Maximilian Kaske
and committed by
GitHub
b44e73a8
83a8879d
+103
-1
apps/web/public/assets/posts/status-page-components/form-components.png
apps/web/public/assets/posts/status-page-components/form-components.png
This is a binary file and will not be displayed.
apps/web/public/assets/posts/status-page-components/status-page-components.png
apps/web/public/assets/posts/status-page-components/status-page-components.png
This is a binary file and will not be displayed.
+1
-1
apps/web/src/content/pages/blog/2026-roadmap.mdx
+1
-1
apps/web/src/content/pages/blog/2026-roadmap.mdx
···
2
2
title: "Openstatus 2025 Year in Review: Lessons Learned and What’s Next"
3
3
description: "As we close out 2025, it’s the perfect time to pause, reflect, and share where we are heading for 2026."
4
4
author: "Thibault Le Ouay Ducasse"
5
-
publishedAt: "2025-12-1"
5
+
publishedAt: "2025-12-01"
6
6
image: "/assets/posts/2026-roadmap/2026.png"
7
7
category: "company"
8
8
---
+102
apps/web/src/content/pages/blog/status-page-components.mdx
+102
apps/web/src/content/pages/blog/status-page-components.mdx
···
1
+
---
2
+
title: "Introducing Status Page Components"
3
+
description: "A major architectural refactor that decouples status pages from monitors, enabling flexible status reporting and better self-hosting support."
4
+
author: "Maximilian Kaske"
5
+
publishedAt: "2026-01-30"
6
+
image: "/assets/posts/status-page-components/status-page-components.png"
7
+
category: "company"
8
+
---
9
+
10
+
Status pages started simple for us: a page showed the uptime of a monitor. That assumption shaped our entire data model - and eventually became our biggest limitation.
11
+
12
+
We embraced this tight coupling early on because it let us move fast. The downside? It made us move slow when requirements evolved.
13
+
14
+
Over the year, we've received requests from users wanting to share status reports without any uptime monitoring attached. We tried addressing this with the `page.configuration` object - you could choose between bar type, card value, and showing uptime - but that was us duct-taping a more fundamental problem: status page components were tightly coupled to monitors.
15
+
16
+
## The Solution
17
+
18
+
From the ground up, we've reworked the relationships between status reports, maintenances, pages, and monitors. The result: **page components** - a flexible new architecture that decouples status pages from monitors.
19
+
20
+
```
21
+
┌──────────────────────────────────────────────────────────────┐
22
+
│ BEFORE (monitors_to_pages) │
23
+
└──────────────────────────────────────────────────────────────┘
24
+
25
+
incidents ───▶ monitors ◀─── maintenances
26
+
│ ◀─── status_reports
27
+
│
28
+
▼
29
+
monitors_to_pages (m-to-m)
30
+
│
31
+
▼
32
+
pages
33
+
34
+
35
+
┌──────────────────────────────────────────────────────────────┐
36
+
│ AFTER (page_components) │
37
+
└──────────────────────────────────────────────────────────────┘
38
+
39
+
incidents ───▶ monitors
40
+
│
41
+
│ (optional)
42
+
▼
43
+
page_components ◀─── maintenances
44
+
│ ◀─── status_reports
45
+
▼
46
+
pages
47
+
```
48
+
49
+
## Component Types
50
+
51
+
A **page component** has a `type` that determines its behavior:
52
+
53
+
- **static**: zero dependency on any uptime data—simply shows values based on connected status reports or maintenances
54
+
- **monitor**: acts just like before where uptime data _can be_ tightly linked to our monitoring system (see `page.configuration` for more)
55
+
56
+
### Future Types
57
+
58
+
These types can be extended. We see **third-party** as a big third pillar where status updates from third-party services can be displayed in near real-time. Feel free to [reach out to us](mailto:ping@openstatus.dev) if you're interested in those components.
59
+
60
+
<Image src="/assets/posts/status-page-components/form-components.png" alt="Page components form, grouped by regions" />
61
+
62
+
## Key Benefits
63
+
64
+
This architectural change brings several advantages:
65
+
66
+
- **Flexibility**: Status pages are no longer limited to monitored services—share status updates for any component, monitored or not
67
+
- **Simplified self-hosting**: Self-hosters can create status pages without setting up a full monitoring infrastructure
68
+
- **Future extensibility**: The component-based architecture makes it easy to add new types like third-party integrations
69
+
- **Better separation of concerns**: Monitoring and status reporting are now properly decoupled, allowing each to evolve independently
70
+
71
+
## Pricing and Plan Limits
72
+
73
+
Page components are counted across your workspace based on your plan tier:
74
+
75
+
- **Hobby (free)**: 3 components
76
+
- **Starter**: 20 components
77
+
- **Pro**: 50 components
78
+
79
+
The flexibility of **static components** means you can now maximize your plan limits more effectively. Previously, every component required a monitor (which counts against your monitor limit). Now you can:
80
+
81
+
- Use monitor-type components for services you want to actively check
82
+
- Use static components for third-party dependencies, managed services, or components you update manually
83
+
- Mix both types to get full visibility without needing a monitor for everything
84
+
85
+
## Migration Approach
86
+
87
+
Our strategy was to sync the legacy database while incrementally migrating every part of our stack:
88
+
89
+
- database migration + setup syncing between `monitors_to_pages` and `page_components` tables
90
+
- status page
91
+
- status reports and maintenances
92
+
- dashboard form
93
+
- status report emails
94
+
- ...
95
+
96
+
This allowed us to step by step test and merge changes to production without having to pause the migration.
97
+
98
+
## API Compatibility
99
+
100
+
For existing integrations, the **v1 API maintains backward compatibility**. Status page responses continue to include the legacy `monitorIds` and `monitors` fields to prevent breaking changes. However, these fields now only return page components of type `monitor` - the `static` components are excluded from these legacy fields.
101
+
102
+
**Looking ahead:** Future API versions will use the `pageComponents` structure as the primary interface. Thibault is already cooking our v2 API version including an SDK to improve the DX around openstatus!