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

This is a binary file and will not be displayed.

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
··· 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
··· 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!