+4 -1

apps/checker/http.go

··· 112 112 start := time.Now() 113 113 114 114 response, err := client.Do(req) 115 115 - timing.TransferDone = time.Now().UTC().UnixMilli() 116 115 latency := time.Since(start).Milliseconds() 116 116 + 117 117 if err != nil { 118 118 119 119 var urlErr *url.Error ··· 134 134 defer response.Body.Close() 135 135 136 136 body, err := io.ReadAll(response.Body) 137 137 + 138 138 + timing.TransferDone = time.Now().UTC().UnixMilli() 139 139 + 137 140 if err != nil { 138 141 return Response{ 139 142 Latency: latency,

+114 -210

apps/docs/astro.config.mjs

··· 4 4 import { defineConfig, envField } from "astro/config"; 5 5 import starlightImageZoom from "starlight-image-zoom"; 6 6 import starlightLlmsTxt from "starlight-llms-txt"; 7 7 - import starlightSidebarTopics from "starlight-sidebar-topics"; 8 7 9 8 import Icons from "unplugin-icons/vite"; 10 9 ··· 58 57 "./src/global.css", 59 58 "./src/custom.css", 60 59 ], 61 61 - plugins: [ 62 62 - starlightSidebarTopics([ 63 63 - { 64 64 - label: "Documentation", 65 65 - link: "/", 66 66 - id: "docs", 67 67 - icon: "open-book", 68 68 - items: [ 69 69 - { 70 70 - label: "Getting Started", 71 71 - items: [ 72 72 - { 73 73 - label: "Introduction", 74 74 - slug: "getting-started/introduction", 75 75 - }, 76 76 - ], 77 77 - }, 78 78 - { 79 79 - label: "Monitoring", 80 80 - items: [ 81 81 - { label: "Overview", slug: "monitoring/overview" }, 82 82 - { 83 83 - label: "Create a monitor", 84 84 - slug: "monitoring/create-monitor", 85 85 - }, 86 86 - { 87 87 - label: "Monitoring as Code", 88 88 - slug: "monitoring/monitoring-as-code", 89 89 - }, 90 90 - { 91 91 - label: "View your results data", 92 92 - slug: "monitoring/monitor-data-collected", 93 93 - }, 94 94 - { 95 95 - label: "Group your checks", 96 96 - slug: "monitoring/group-monitor-tag", 97 97 - }, 98 98 - { 99 99 - label: "Clone a check", 100 100 - slug: "monitoring/clone-monitor", 101 101 - }, 102 102 - { 103 103 - label: "OpenTelemetry", 104 104 - slug: "monitoring/opentelemetry", 105 105 - }, 106 106 - { 107 107 - label: "Check Types", 108 108 - collapsed: true, 109 109 - items: [ 110 110 - { 111 111 - label: "HTTP", 112 112 - slug: "monitoring/type/http", 113 113 - }, 114 114 - { 115 115 - label: "TCP", 116 116 - slug: "monitoring/type/tcp", 117 117 - }, 118 118 - ], 119 119 - }, 120 120 - { 121 121 - label: "Customizations", 122 122 - collapsed: true, 123 123 - items: [ 124 124 - { 125 125 - label: "Assertions", 126 126 - slug: "monitoring/customization/assertions", 127 127 - }, 128 128 - { 129 129 - label: "Frequency", 130 130 - slug: "monitoring/customization/frequency", 131 131 - }, 132 132 - { 133 133 - label: "Notifications", 134 134 - slug: "monitoring/customization/notification", 135 135 - }, 136 136 - { 137 137 - label: "Locations", 138 138 - slug: "monitoring/customization/locations", 139 139 - }, 140 140 - { 141 141 - label: "Timing", 142 142 - slug: "monitoring/customization/timing", 143 143 - }, 144 144 - { 145 145 - label: "Follow Redirects", 146 146 - slug: "monitoring/customization/follow-redirects", 147 147 - }, 148 148 - ], 149 149 - }, 150 150 - ], 151 151 - collapsed: false, 152 152 - }, 153 153 - { 154 154 - label: "Status Page", 155 155 - collapsed: true, 156 156 - 157 157 - items: [ 158 158 - { label: "Overview", slug: "status-page/overview" }, 159 159 - { 160 160 - label: "Create your status page", 161 161 - slug: "status-page/create-status-page", 162 162 - }, 163 163 - 164 164 - { 165 165 - label: "Work with Status Page", 166 166 - autogenerate: { directory: "status-page/work" }, 167 167 - collapsed: false, 168 168 - }, 169 169 - { 170 170 - label: "Advanced", 171 171 - autogenerate: { directory: "status-page/advanced" }, 172 172 - collapsed: true, 173 173 - }, 174 174 - ], 175 175 - }, 176 176 - { 177 177 - label: "Incidents", 178 178 - collapsed: true, 179 179 - items: [ 180 180 - { label: "Overview", slug: "incident/overview" }, 181 181 - { 182 182 - label: "Work with incident", 183 183 - slug: "incident/work-with-incident", 184 184 - }, 60 60 + sidebar: [ 61 61 + { 62 62 + label: "Concepts", 63 63 + items: [ 64 64 + { 65 65 + label: "About Uptime monitoring", 66 66 + slug: "concept/uptime-monitoring", 67 67 + }, 68 68 + { 69 69 + label: "Best Practices for Status Pages", 70 70 + slug: "concept/best-practices-status-page", 71 71 + }, 72 72 + { 73 73 + label: "Uptime Monitoring as Code", 74 74 + slug: "concept/uptime-monitoring-as-code", 75 75 + }, 76 76 + { 77 77 + label: "Latency vs Response Time", 78 78 + slug: "concept/latency-vs-response-time", 79 79 + }, 80 80 + ], 81 81 + }, 82 82 + { 83 83 + label: "Tutorials", 84 84 + items: [ 85 85 + { 86 86 + label: "How to create a monitor", 87 87 + slug: "tutorial/how-to-create-monitor", 88 88 + }, 89 89 + { 90 90 + label: "How to create a status page", 91 91 + slug: "tutorial/how-to-create-status-page", 92 92 + }, 93 93 + { 94 94 + label: "Get Started with OpenStatus CLI", 95 95 + slug: "tutorial/get-started-with-openstatus-cli", 96 96 + }, 97 97 + ], 98 98 + }, 185 99 186 186 - { 187 187 - label: "Incident Detail", 188 188 - slug: "incident/incident-detail", 189 189 - }, 190 190 - ], 191 191 - }, 192 192 - { 193 193 - label: "Alerting", 194 194 - collapsed: true, 195 195 - items: [ 196 196 - { label: "Overview", slug: "alerting/overview" }, 197 197 - { 198 198 - label: "Notification Channels", 199 199 - autogenerate: { 200 200 - directory: "alerting/providers", 201 201 - collapsed: true, 202 202 - }, 203 203 - }, 204 204 - ], 205 205 - }, 206 206 - { 207 207 - label: "Developer Tools", 208 208 - collapsed: true, 209 209 - autogenerate: { directory: "tools" }, 210 210 - }, 211 211 - { 212 212 - label: "Support", 213 213 - collapsed: true, 214 214 - items: [ 215 215 - { 216 216 - label: "Help", 217 217 - slug: "help/support", 218 218 - collapsed: true, 219 219 - }, 220 220 - ], 221 221 - }, 222 222 - ], 223 223 - }, 224 224 - { 225 225 - label: "CLI", 226 226 - icon: "seti:powershell", 227 227 - link: "/cli/getting-started", 228 228 - items: [ 229 229 - { 230 230 - label: "CLI", 231 231 - items: [ 232 232 - { 233 233 - label: "Getting Started", 234 234 - slug: "cli/getting-started", 235 235 - }, 236 236 - { 237 237 - label: "Commands", 238 238 - autogenerate: { directory: "cli/commands" }, 239 239 - }, 240 240 - ], 241 241 - }, 242 242 - ], 243 243 - }, 244 244 - { 245 245 - label: "API Reference", 246 246 - icon: "puzzle", 247 247 - link: "https://api.openstatus.dev/v1", 248 248 - }, 249 249 - { 250 250 - label: "Guides", 251 251 - icon: "rocket", 252 252 - link: "/guides/introduction", 253 253 - items: [ 254 254 - { 255 255 - label: "Guides", 256 256 - autogenerate: { directory: "guides" }, 257 257 - }, 258 258 - ], 259 259 - }, 260 260 - { 261 261 - label: "Contributing", 262 262 - icon: "heart", 263 263 - link: "/contributing/getting-started", 264 264 - items: [ 265 265 - { 266 266 - label: "Contributing", 267 267 - autogenerate: { directory: "contributing" }, 100 100 + { 101 101 + label: "Guides", 102 102 + items: [ 103 103 + { 104 104 + label: "Monitor your MCP Server", 105 105 + slug: "guides/how-to-monitor-mcp-server", 106 106 + }, 107 107 + { 108 108 + label: "Run check in GitHub Actions", 109 109 + slug: "guides/how-to-run-synthetic-test-github-action", 110 110 + }, 111 111 + { 112 112 + label: "Export Metrics to your OTLP Endpoint", 113 113 + slug: "guides/how-to-export-metrics-to-otlp-endpoint", 114 114 + }, 115 115 + { 116 116 + label: "How to Add an SVG Status Badge to your GitHub README", 117 117 + slug: "guides/how-to-add-svg-status-badge", 118 118 + }, 119 119 + { 120 120 + label: "How to use React Status Widget", 121 121 + slug: "guides/how-to-use-react-widget", 122 122 + }, 123 123 + ], 124 124 + }, 125 125 + { 126 126 + label: "Reference", 127 127 + items: [ 128 128 + { 129 129 + label: "CLI Reference", 130 130 + slug: "reference/cli-reference", 131 131 + }, 132 132 + { 133 133 + label: "API Reference", 134 134 + link: "https://api.openstatus.dev/v1", 135 135 + // badge: { text: 'External' }, 136 136 + attrs: { 137 137 + target: "_blank", 268 138 }, 269 269 - ], 270 270 - }, 271 271 - ]), 139 139 + }, 140 140 + { 141 141 + label: "Incident", 142 142 + slug: "reference/incident", 143 143 + }, 144 144 + { 145 145 + label: "HTTP Monitor", 146 146 + slug: "reference/http-monitor", 147 147 + }, 148 148 + { 149 149 + label: "TCP Monitor", 150 150 + slug: "reference/tcp-monitor", 151 151 + }, 152 152 + { 153 153 + label: "Notification", 154 154 + slug: "reference/notification", 155 155 + }, 156 156 + { 157 157 + label: "Status Page", 158 158 + slug: "reference/status-page", 159 159 + }, 160 160 + { 161 161 + label: "Status Report", 162 162 + slug: "reference/status-report", 163 163 + }, 164 164 + { 165 165 + label: "Subscriber", 166 166 + slug: "reference/subscriber", 167 167 + }, 168 168 + { 169 169 + label: "Terraform Provider", 170 170 + slug: "reference/terraform", 171 171 + }, 172 172 + ], 173 173 + }, 174 174 + ], 175 175 + plugins: [ 272 176 starlightLlmsTxt({ 273 177 projectName: "OpenStatus Documentation", 274 178 description:

apps/docs/src/assets/guides/how-to-export-metrics-via-otel/grafana.png

This is a binary file and will not be displayed.

apps/docs/src/assets/guides/how-to-export-metrics-via-otel/honeycomb.jpg

This is a binary file and will not be displayed.

apps/docs/src/assets/guides/how-to-export-metrics-via-otel/newrelic.jpg

This is a binary file and will not be displayed.

apps/docs/src/assets/guides/how-to-export-metrics-via-otel/signoz.jpg

This is a binary file and will not be displayed.

apps/docs/src/assets/monitor/create-monitor/create-monitor-1.png apps/docs/src/assets/tutorial/create-monitor/create-monitor-1.png

apps/docs/src/assets/monitor/create-monitor/create-monitor-2.png apps/docs/src/assets/tutorial/create-monitor/create-monitor-2.png

apps/docs/src/assets/monitor/create-monitor/monitor-overview.png apps/docs/src/assets/tutorial/create-monitor/monitor-overview.png

apps/docs/src/assets/tutorial/create-status-page/create-status-page-1.png

This is a binary file and will not be displayed.

apps/docs/src/assets/tutorial/create-status-page/create-status-page-2.png

This is a binary file and will not be displayed.

apps/docs/src/assets/tutorial/get-started-with-openstatus-cli/CLI.png

This is a binary file and will not be displayed.

+3 -2

apps/docs/src/components/Footer.astro

··· 15 15 <span>Show your support! Star us on GitHub ⭐️</span> 16 16 <a class="github-button" href="https://github.com/openstatusHQ/openstatus" data-color-scheme="no-preference: light; light: light; dark: light;" data-icon="octicon-star" data-size="large" data-show-count="true" aria-label="Star openstatusHQ/openstatus on GitHub">Star</a> 17 17 </div> 18 18 - 19 18 <div class="flex items-center justify-center"> 20 20 - <img src='https://status.openstatus.dev/badge'> 19 19 + <a href="https://status.openstatus.dev" target="_blank" > 20 20 + <img src='https://status.openstatus.dev/badge/v2?variant=outline'> 21 21 + </a> 21 22 </div> 22 23 </footer> 23 24

+55 -10

apps/docs/src/content/docs/cli/commands/monitors.mdx apps/docs/src/content/docs/reference/cli-reference.mdx

··· 1 1 --- 2 2 - title: monitors 3 3 - description: "Manage your monitors in OpenStatus from the command line" 2 2 + title: CLI Reference 4 3 --- 5 4 6 6 - x 7 7 - ### `monitors` command 5 5 + ## CLI interface - openstatus 8 6 9 9 - The monitors command is used to manage your monitors. You can import, update, delete, trigger, view and list your monitors using this command. 7 7 + OpenStatus is a command line interface for managing your monitors and triggering your synthetics tests. 10 8 9 9 + This is OpenStatus Command Line Interface, the OpenStatus.dev CLI. 10 10 + 11 11 + Usage: 12 12 + 13 13 + ```bash 14 14 + $ openstatus [COMMAND] [COMMAND FLAGS] [ARGUMENTS...] 15 15 + ``` 16 16 + 17 17 + ### `monitors` command 18 18 + 19 19 + Manage your monitors. 11 20 12 21 Usage: 13 22 14 23 ```bash 15 24 $ openstatus [GLOBAL FLAGS] monitors [ARGUMENTS...] 16 25 ``` 17 17 - **--access-token, -t**="": OpenStatus API Access Token 18 26 19 27 ### `monitors apply` subcommand 20 28 ··· 23 31 > openstatus monitors apply [options] 24 32 25 33 Creates or updates monitors according to the OpenStatus configuration file. 26 26 - 27 27 - You can find some examples in the OpenStatus Template repository: 28 28 - 29 29 - [https://github.com/openstatusHQ/cli-template/](https://github.com/openstatusHQ/cli-template/) 30 34 31 35 Usage: 32 36 ··· 124 128 | Name | Description | Default value | Environment variables | 125 129 |-----------------------------|-----------------------------|:-------------:|:----------------------:| 126 130 | `--access-token="…"` (`-t`) | OpenStatus API Access Token | | `OPENSTATUS_API_TOKEN` | 131 131 + 132 132 + ### `run` command (aliases: `r`) 133 133 + 134 134 + Run your synthetics tests. 135 135 + 136 136 + > openstatus run [options] 137 137 + 138 138 + Run the synthetic tests defined in the config.openstatus.yaml. 139 139 + 140 140 + Usage: 141 141 + 142 142 + ```bash 143 143 + $ openstatus [GLOBAL FLAGS] run [COMMAND FLAGS] [ARGUMENTS...] 144 144 + ``` 145 145 + 146 146 + The following flags are supported: 147 147 + 148 148 + | Name | Description | Default value | Environment variables | 149 149 + |-----------------------------|-----------------------------|:------------------------:|:----------------------:| 150 150 + | `--config="…"` | The configuration file | `config.openstatus.yaml` | *none* | 151 151 + | `--access-token="…"` (`-t`) | OpenStatus API Access Token | | `OPENSTATUS_API_TOKEN` | 152 152 + 153 153 + ### `whoami` command (aliases: `w`) 154 154 + 155 155 + Get your workspace information. 156 156 + 157 157 + > openstatus whoami [options] 158 158 + 159 159 + Get your current workspace information, display the workspace name, slug, and plan. 160 160 + 161 161 + Usage: 162 162 + 163 163 + ```bash 164 164 + $ openstatus [GLOBAL FLAGS] whoami [COMMAND FLAGS] [ARGUMENTS...] 165 165 + ``` 166 166 + 167 167 + The following flags are supported: 168 168 + 169 169 + | Name | Description | Default value | Environment variables | 170 170 + |-----------------------------|-----------------------------|:-------------:|:----------------------:| 171 171 + | `--access-token="…"` (`-t`) | OpenStatus API Access Token | | `OPENSTATUS_API_TOKEN` |

-33

apps/docs/src/content/docs/cli/commands/run.mdx

··· 1 1 - --- 2 2 - title: run 3 3 - description: "How to run a list of synthetic checks in OpenStatus from the command line" 4 4 - --- 5 5 - 6 6 - ### `run` command (aliases: `r`) 7 7 - 8 8 - Run your synthetics tests. 9 9 - 10 10 - > openstatus run [options] 11 11 - 12 12 - Run the synthetic tests defined in the `config.openstatus.yaml`. 13 13 - The config file should be in the following format: 14 14 - 15 15 - ```yaml 16 16 - tests: 17 17 - ids: 18 18 - - monitor-id-1 19 19 - - monitor-id-2 20 20 - ``` 21 21 - 22 22 - Usage: 23 23 - 24 24 - ```bash 25 25 - $ openstatus [GLOBAL FLAGS] run [COMMAND FLAGS] [ARGUMENTS...] 26 26 - ``` 27 27 - 28 28 - The following flags are supported: 29 29 - 30 30 - | Name | Description | Default value | Environment variables | 31 31 - |-----------------------------|-----------------------------|:------------------------:|:----------------------:| 32 32 - | `--config="…"` | The configuration file | `config.openstatus.yaml` | *none* | 33 33 - | `--access-token="…"` (`-t`) | OpenStatus API Access Token | | `OPENSTATUS_API_TOKEN` |

-12

apps/docs/src/content/docs/cli/commands/whoami.mdx

··· 1 1 - --- 2 2 - title: whoami 3 3 - description: "How to check the currently authenticated user in OpenStatus with the whoami command" 4 4 - --- 5 5 - 6 6 - The `whoami` command is used to display the currently authenticated user. This command is useful to check if you are logged in and to see the workspace details. 7 7 - 8 8 - ``` 9 9 - openstatus whoami [options] 10 10 - ``` 11 11 - 12 12 - **--access-token, -t**="": OpenStatus API Access Token

-72

apps/docs/src/content/docs/cli/getting-started.mdx

··· 1 1 - --- 2 2 - title: Getting Started 3 3 - description: "Get started with OpenStatus CLI and start triggering your synthetic checks from your terminal" 4 4 - --- 5 5 - 6 6 - import { Image } from 'astro:assets'; 7 7 - 8 8 - import CLI from '../../../assets/cli/CLI.png'; 9 9 - 10 10 - <Image 11 11 - src={CLI} 12 12 - alt="OpenStatus CLI" 13 13 - /> 14 14 - 15 15 - 16 16 - 17 17 - You can use the OpenStatus CLI to manage and run your monitors. The CLI is a powerful tool that allows you to interact with OpenStatus from your terminal. 18 18 - 19 19 - ## Installation 20 20 - 21 21 - You can install the OpenStatus CLI using brew. 22 22 - 23 23 - #### Windows 24 24 - ```powershell 25 25 - iwr instl.sh/openstatushq/cli/windows | iex 26 26 - ``` 27 27 - 28 28 - #### macOS 29 29 - ```bash 30 30 - brew install openstatusHQ/cli/openstatus --cask 31 31 - ``` 32 32 - 33 33 - or 34 34 - 35 35 - 36 36 - ```bash 37 37 - curl -sSL instl.sh/openstatushq/cli/macos | bash 38 38 - ``` 39 39 - 40 40 - 41 41 - 42 42 - #### Linux 43 43 - ```bash 44 44 - curl -sSL instl.sh/openstatushq/cli/linux | bash 45 45 - ``` 46 46 - 47 47 - 48 48 - 49 49 - Then you can run the following command to verify the installation. 50 50 - 51 51 - ```bash 52 52 - openstatus --help 53 53 - ``` 54 54 - 55 55 - 56 56 - ## Usage 57 57 - 58 58 - You need to get an API token to use the CLI. You can get an API key by signing up on the OpenStatus website. 59 59 - 60 60 - _Settings &rarr; API Token &rarr; Create API token_ 61 61 - 62 62 - You can set the API token using the following command. 63 63 - 64 64 - ```bash 65 65 - export OPENSTATUS_API_TOKEN=your-api-token 66 66 - ``` 67 67 - 68 68 - or you can set the `--access-token` option in the CLI command. 69 69 - 70 70 - ```bash 71 71 - openstatus [COMMAND] --access-token your-api-token 72 72 - ```

+79

apps/docs/src/content/docs/concept/best-practices-status-page.mdx

··· 1 1 + --- 2 2 + title: Best Practices for Status Pages 3 3 + --- 4 4 + 5 5 + 6 6 + ``` 7 7 + +------------------------------------------------+ 8 8 + | openstatus Status Page | 9 9 + +------------------------------------------------+ 10 10 + | Service Name | Status | Uptime | 11 11 + +-------------------+--------+-------------------+ 12 12 + | Web Server | ✅ OK | 99.9% | 13 13 + | Database | ✅ OK | 99.8% | 14 14 + | API Gateway | ⚠️ Degraded | 99.5% | 15 15 + | Monitoring | ✅ OK | 100% | 16 16 + | Payment Processing| ✅ OK | 99.7% | 17 17 + +-------------------+--------+-------------------+ 18 18 + | Incidents: | 19 19 + | | 20 20 + | - Degraded performance on API Gateway due | 21 21 + | to high traffic. Our team is investigating.| 22 22 + +------------------------------------------------+ 23 23 + ``` 24 24 + 25 25 + Status pages are essential tools for communicating service health and incidents to users. They build trust by providing transparency and should be a core component of any software company's communication strategy. Following a set of best practices ensures your status page is effective and helpful. 26 26 + 27 27 + 28 28 + 29 29 + 30 30 + ## Best Practices for a Status Page 31 31 + 32 32 + ### Maintain Transparency and Honesty 33 33 + 34 34 + A status page's primary goal is to be a single source of truth. Be upfront about issues, even minor ones. Hiding problems erodes user trust and can lead to more support requests. 35 35 + 36 36 + - **Communicate Clearly:** Use simple, non-technical language. Users shouldn't need a dictionary to understand what's happening. 37 37 + 38 38 + - **Be Timely:** Update the page as soon as an incident is confirmed and provide regular updates throughout the resolution process. 39 39 + 40 40 + ### Automate Where Possible 41 41 + 42 42 + Manual updates during an outage are prone to error and can be slow. Automating your status page can provide more accurate and timely information. 43 43 + 44 44 + - **Integrate Monitoring Tools:** Connect your internal monitoring and alerting systems to your status page. When a metric crosses a threshold (e.g., high error rate), the status page can automatically be updated. 45 45 + 46 46 + - **Use an API:** we provide APIs that allow you to programmatically update component statuses and post new incidents. 47 47 + 48 48 + 49 49 + ### Provide Detailed Incident Communication 50 50 + 51 51 + When an incident occurs, provide a detailed and structured narrative. 52 52 + 53 53 + - **Start with the "What":** State the problem clearly and concisely. 54 54 + 55 55 + - **Follow with the "Why":** Briefly explain the root cause, if known. 56 56 + 57 57 + - **Conclude with the "How" and "When":** Explain the steps being taken to resolve the issue and provide an estimated time to resolution. 58 58 + 59 59 + **Example Incident Update:** 60 60 + 61 61 + - **Investigating:** "We're currently investigating an issue affecting user logins." 62 62 + 63 63 + - **Identified:** "We've identified the root cause as a database connection issue and are working on a fix." 64 64 + 65 65 + - **Monitoring:** "A fix has been deployed, and we're monitoring the system's performance." 66 66 + 67 67 + - **Resolved:** "The issue has been resolved, and all services are now operational." 68 68 + 69 69 + 70 70 + ### Make it Easily Accessible 71 71 + 72 72 + Your status page should be easy to find. 73 73 + 74 74 + - **Prominent Link:** Place a link to your status page in your application's footer, on your website, and in your support documentation. 75 75 + 76 76 + - **Custom Domain:** Use a simple, memorable URL like status.yourcompany.com. 77 77 + 78 78 + 79 79 + Following these practices turns your status page from a passive communication tool into an active driver of customer trust and confidence.

+14

apps/docs/src/content/docs/concept/getting-started.mdx

··· 1 1 + --- 2 2 + title: Getting Started 3 3 + --- 4 4 + 5 5 + 6 6 + Here’s some content to help you get started with the concept behind OpenStatus. 7 7 + 8 8 + - [Uptime Monitoring](/tutorial/uptime-monitoring) 9 9 + 10 10 + - [Best Practices for Status Pages](/tutorial/best-practices-status-page) 11 11 + 12 12 + - [Uptime Monitoring as Code](/tutorial/uptime-monitoring-as-code) 13 13 + 14 14 + - [Latency vs Response Time](/tutorial/latency-vs-response-time)

+71

apps/docs/src/content/docs/concept/latency-vs-response-time.mdx

··· 1 1 + --- 2 2 + title: Latency vs Response Time for a request 3 3 + --- 4 4 + 5 5 + Latency and response time are two different metrics used in uptime monitoring. Latency measures the time it takes for a request to travel from the probes to the server and back. Response time is the time it takes for the server to process the request and send back a response, plus the latency. 6 6 + 7 7 + ## What is Latency? 8 8 + 9 9 + ``` 10 10 + openstatus Network Server (Website) 11 11 + | | | 12 12 + |------- Request ---------->| | 13 13 + | (Timestamp A: Send) | | 14 14 + | |------- Process --------->| 15 15 + | | (Server processing time) | 16 16 + | |<------- Response --------| 17 17 + | | (Timestamp B: Receive) | 18 18 + | | | 19 19 + Latency = Timestamp B - Timestamp A 20 20 + ``` 21 21 + 22 22 + Latency is the time it takes for data to travel from its source to its destination. Think of it as the round-trip time (RTT) for a network packet. This delay is influenced by several factors: 23 23 + 24 24 + - **Distance:** The physical distance between the client and the server. Data traveling across continents will have higher latency than data traveling within the same city. 25 25 + 26 26 + - **Network Congestion:** When too much data is on the network, it can slow down transmission, similar to a traffic jam on a highway. 27 27 + 28 28 + To measure latency, you can monitor endpoints like `/ping` or `/healthcheck` with minimum server processing time. 29 29 + 30 30 + ## What Is Response Time? 31 31 + 32 32 + ``` 33 33 + openstatus Network Server 34 34 + | | | 35 35 + (Start) |------- Request -------->| | 36 36 + (T1) | | | 37 37 + | |--- Processing ----->| 38 38 + | | (Server's work) | 39 39 + | |<-- Response Data ---| 40 40 + | | | 41 41 + (End) |<--- (Received) ---------| | 42 42 + (T2) | | | 43 43 + 44 44 + Response Time = T2 - T1 45 45 + ``` 46 46 + 47 47 + 48 48 + Response time is the total time from the moment a user's request is sent until the moment the first byte of the server's response is received. It includes both the network latency and the server's processing time. 49 49 + 50 50 + Response time = Network Latency + Server Processing Time 51 51 + 52 52 + The server processing time is the duration the server spends on tasks like: 53 53 + 54 54 + - Executing database queries. 55 55 + - Running application logic. 56 56 + - Generating the HTML or JSON response. 57 57 + 58 58 + A high response time often indicates a problem with the server-side application itself. For example, slow database queries or inefficient can dramatically increase the response time, even if the network latency is low. 59 59 + 60 60 + 61 61 + ## Why the Distinction Matters for Uptime Monitoring 62 62 + 63 63 + Understanding the difference between these two metrics is crucial for diagnosing performance issues. 64 64 + 65 65 + - If your monitoring shows a **high response time but low latency**, the problem is likely with your server's performance. You should investigate your application's code, database queries, and server resources. 66 66 + 67 67 + - If both your **latency and response time** are high, the issue is likely network-related. This could be due to a poor connection between the monitoring location and your server, or a broader network issue. 68 68 + 69 69 + - **Response time is the ultimate measure of user experience** because it reflects the full journey of a request. Users don't just care how fast a packet can get to the server; they care how long it takes to see the results. 70 70 + 71 71 + By monitoring both metrics, you can quickly pinpoint whether a performance slowdown is caused by your application or by the network.

+90

apps/docs/src/content/docs/concept/uptime-monitoring-as-code.mdx

··· 1 1 + --- 2 2 + title: Uptime Monitoring as Code 3 3 + --- 4 4 + import { Code } from '@astrojs/starlight/components'; 5 5 + export const code = ` 6 6 + # yaml-language-server: $schema=https://www.openstatus.dev/schema.json 7 7 + uptime-monitor: 8 8 + name: "Uptime Monitor" 9 9 + description: "Uptime monitoring example" 10 10 + frequency: "10m" 11 11 + active: true 12 12 + regions: 13 13 + - iad 14 14 + - ams 15 15 + - syd 16 16 + - jnb 17 17 + - gru 18 18 + retry: 3 19 19 + kind: http 20 20 + request: 21 21 + url: https://openstat.us 22 22 + method: GET 23 23 + headers: 24 24 + User-Agent: OpenStatus 25 25 + assertions: 26 26 + - kind: statusCode 27 27 + compare: eq 28 28 + target: 200 29 29 + 30 30 + graphql-monitor: 31 31 + name: "Graphql" 32 32 + description: "GitHub GraphQL API" 33 33 + frequency: "10m" 34 34 + active: true 35 35 + regions: 36 36 + - iad 37 37 + - ams 38 38 + - syd 39 39 + - jnb 40 40 + - gru 41 41 + retry: 3 42 42 + kind: http 43 43 + request: 44 44 + url: https://api.github.com/graphql 45 45 + method: POST 46 46 + headers: 47 47 + User-Agent: OpenStatus 48 48 + Authorization: Bearer YOUR_TOKEN_HERE 49 49 + body: | 50 50 + { 51 51 + "query": "query { viewer { login }}" 52 52 + } 53 53 + ` 54 54 + 55 55 + Uptime monitoring is a vital part of any robust system, ensuring your services are online and available to users. Historically, this has involved manually configuring monitors through a web interface, which can be tedious and prone to human error. Uptime Monitoring as Code changes this by treating your monitoring configurations like any other part of your application—as code. 56 56 + 57 57 + 58 58 + ## Why Use Uptime Monitoring as Code? 59 59 + 60 60 + This approach offers significant advantages: 61 61 + 62 62 + - **Version Control:** By defining your monitors in a YAML file, you can track every change, rollback to previous versions, and see who made which modifications using tools like Git. This is crucial for auditing and troubleshooting. 63 63 + 64 64 + - **Automation and Consistency:** Your monitoring setup can be part of your automated deployment pipeline. When you deploy a new service, its monitors are created automatically, ensuring consistency across your entire infrastructure. This eliminates the risk of forgetting to set up monitoring for a new service. 65 65 + 66 66 + - **Collaboration:** A code-based approach simplifies collaboration among teams. A developer can create a new monitor definition in the YAML file and submit it for peer review, just as they would with any other code change. This promotes a shared understanding of your system's health. 67 67 + 68 68 + - **Scalability:** Manually setting up hundreds of monitors is a nightmare. With a code-based approach, you can programmatically generate configurations for a large number of services, making it easy to scale your monitoring as your infrastructure grows. 69 69 + 70 70 + - **Simplified Auditing:** Since the entire configuration is in a file, it's easy to see the current state of your monitors at a glance. You don't have to navigate through multiple screens in a web UI. 71 71 + 72 72 + 73 73 + ## How It Works with openstatus 74 74 + 75 75 + We offer the use ofa simple, human-readable YAML file to define all uptime monitors. This file serves as the single source of truth for your monitoring setup. You define each monitor with its URL, expected status code, and other parameters. 76 76 + 77 77 + Here’s an example of what your `openstatus.yaml` file might look like: 78 78 + 79 79 + <Code code={code} lang="yaml" title='openstatus.yaml' /> 80 80 + 81 81 + ### Making Changes with the CLI 82 82 + 83 83 + Once your `openstatus.yaml` file is ready, you use our [command-line interface (CLI)](tutorial/get-started-with-openstatus-cli) to apply the changes. The CLI compares your local configuration with the current state of your monitors and applies only the necessary changes—creating new monitors, updating existing ones, or deleting those no longer defined. 84 84 + 85 85 + **Common CLI Commands:** 86 86 + 87 87 + - `openstatus monitors apply`: Applies the changes defined in your `openstatus.yaml` file. 88 88 + - `openstatus monitors import`: Import the monitors from your dashboard to a new `openstatus.yaml` file. 89 89 + 90 90 + By integrating this **Uptime Monitoring as Code** workflow into your development lifecycle, you can achieve a more reliable, consistent, and scalable system. It's about moving from manual clicks to automated, version-controlled operations.

+93

apps/docs/src/content/docs/concept/uptime-monitoring.mdx

··· 1 1 + --- 2 2 + title: About Uptime Monitoring 3 3 + --- 4 4 + The concept of **uptime monitoring** refers to the practice of continuously checking the availability of a website, server, or application. It's a proactive measure that alerts you to problems as they happen, helping to minimize downtime and its potential negative impacts. 5 5 + 6 6 + 7 7 + ``` 8 8 + +----------------+ 9 9 + | Service to be | 10 10 + | Monitored | 11 11 + +----------------+ 12 12 + ▲ 13 13 + | 14 14 + | (Network Latency) 15 15 + | 16 16 + +-----+-------+ +-----+-------+ +-----+-------+ 17 17 + | Monitoring | | Monitoring | | Monitoring | 18 18 + | Node (USA) | | Node (EU) | | Node (Asia) | 19 19 + +-----+-------+ +-----+-------+ +-----+-------+ 20 20 + | | | 21 21 + |---------------|-----------------| 22 22 + ▼ ▼ ▼ 23 23 + +------------------------------------------------+ 24 24 + | Global Uptime Monitoring Service | 25 25 + | | 26 26 + | - Sends automated requests (e.g., pings or | 27 27 + | HTTP checks) from all nodes at set intervals | 28 28 + | - Records response time and success/failure | 29 29 + | - Compares results from different nodes | 30 30 + | - If a failure or a slow response is detected, | 31 31 + | it triggers an alert. | 32 32 + +------------------------------------------------+ 33 33 + | 34 34 + | (Alerts: Email, SMS, Slack, etc.) 🔔 35 35 + | 36 36 + +-----+-----+ 37 37 + | Your Team | 38 38 + +-----------+ 39 39 + ``` 40 40 + 41 41 + 42 42 + ## Key Concepts 43 43 + 44 44 + - **Downtime**: The period when a service is unavailable or not functioning as expected. It can be caused by server failures, network issues, software bugs, or even cyberattacks. 45 45 + 46 46 + - **Uptime**: The percentage of time a service is available and operational. A high uptime percentage (e.g., 99.9% or "three nines") indicates reliability. 47 47 + 48 48 + - **Alerting**: The system of notifying a team or individual when downtime is detected. Alerts can be sent via email, SMS, Slack, or other communication channels. 49 49 + 50 50 + ## Why Uptime Monitoring is Crucial 51 51 + 52 52 + - **Business Continuity**: Downtime can lead to significant financial losses, damage to reputation, and loss of customer trust. Uptime monitoring helps you address issues quickly, ensuring your services are always available to your users. 53 53 + 54 54 + - **Performance Insight**: Monitoring tools often provide data on latency and response times, giving you insights into your service's performance beyond just availability. This can help you optimize your infrastructure and user experience. 55 55 + 56 56 + - **Proactive Problem Solving**: Instead of waiting for a customer to report an issue, uptime monitoring allows you to be the first to know about it. This enables you to troubleshoot and resolve problems before they escalate. 57 57 + 58 58 + ## How it Works 59 59 + 60 60 + Uptime monitoring typically involves a monitoring agent that periodically sends a request (like an HTTP GET request) to your service. 61 61 + 62 62 + - If the service responds with a successful status code (e.g., 200 OK), it's considered up. 63 63 + 64 64 + - If the service returns an error code, a timeout, or no response, the agent will perform a re-check from a different location to confirm the outage. This helps prevent false alarms caused by temporary network glitches. 65 65 + 66 66 + - Upon confirmation, the system triggers an alert, notifying the relevant team members. The monitoring system will continue to check the service until it's back online, at which point a recovery alert is often sent. 67 67 + 68 68 + Common types of checks include: 69 69 + 70 70 + - **HTTP/HTTPS checks:** Verify a website is accessible and returns a valid response. 71 71 + - **TCP checks:** Confirm a server is reachable on the network. 72 72 + 73 73 + 74 74 + 75 75 + ## Planning an Uptime Monitoring System 76 76 + 77 77 + When planning your own uptime monitoring system, consider the following: 78 78 + 79 79 + 1. Define What to Monitor: Identify all critical services, websites, APIs, and servers that need to be monitored. Prioritize based on business impact. 80 80 + 81 81 + 2. Select a Monitoring Tool: Choose a tool that fits your needs. Options range from simple free services to complex enterprise-level platforms. Look for features like: 82 82 + 83 83 + - **Multiple locations:** Checks from various geographic regions to ensure global availability. 84 84 + 85 85 + - **Customizable alerting:** Set up different alert thresholds and notification methods. 86 86 + 87 87 + - **Reporting and dashboards:** Visualize uptime history, performance metrics, and incident reports. 88 88 + 89 89 + - **Integrations:** Connect with your existing tools like Slack, PagerDuty, or email. 90 90 + 91 91 + 3. **Establish Alerting Rules:** Determine who should be notified and when. Set up an escalation policy—for example, if a primary on-call engineer doesn't respond within 15 minutes, the alert is sent to a manager. 92 92 + 93 93 + 4. **Regularly Review and Optimize:** Monitor your monitoring system itself. Review historical data to identify recurring issues, fine-tune alert thresholds, and update your list of monitored services as your infrastructure evolves.

+20

apps/docs/src/content/docs/guides/getting-started.mdx

··· 1 1 + --- 2 2 + title: Introduction 3 3 + description: Guides to get started with OpenStatus guides 4 4 + sidebar: 5 5 + label: Introduction 6 6 + order: 1 7 7 + --- 8 8 + 9 9 + Here's some guides for the getting started with OpenStatus. 10 10 + 11 11 + 12 12 + - [How to monitor your MCP Server using OpenStatus](/guides/how-to-monitor-mcp-server/) 13 13 + 14 14 + - [How to run synthetic tests in your GitHub Actions](/guides/how-to-run-synthetic-test-github-action/) 15 15 + 16 16 + - [Export Metrics to your OTLP endpoint](/guides/how-to-export-metrics-to-otlp-endpoint) 17 17 + 18 18 + - [How to Add an SVG Status Badge to your GitHub README](/guides/how-to-add-svg-status-badge) 19 19 + 20 20 + - [How to use React Status Widget](/guides/how-to-use-react-widget)

-69

apps/docs/src/content/docs/guides/how-deploy-checker-koyeb.mdx

··· 1 1 - --- 2 2 - title: How to deploy your own checker on Koyeb 3 3 - description: Learn how to deploy our checker on Koyeb. 4 4 - sidebar: 5 5 - label: Deploy our probe on Koyeb 6 6 - --- 7 7 - import { Image } from 'astro:assets'; 8 8 - 9 9 - import Koyeb1 from '../../../assets/guides/how-deploy-checker-koyeb/koyeb-1.png'; 10 10 - import Koyeb2 from '../../../assets/guides/how-deploy-checker-koyeb/koyeb-2.png'; 11 11 - import Koyeb3 from '../../../assets/guides/how-deploy-checker-koyeb/koyeb-3.png'; 12 12 - 13 13 - 14 14 - ## Introduction 15 15 - 16 16 - You need a koeyb account to deploy our checker on Koyeb. If you don't have one, you can create one [here](https://app.koyeb.com/). 17 17 - 18 18 - ## Deploying the checker 19 19 - 20 20 - 1. Go to the [Koyeb dashboard](https://app.koyeb.com/). 21 21 - 22 22 - 2. Click on the `Create Service` button. 23 23 - 24 24 - 3. Select the `Docker` option. 25 25 - 26 26 - 27 27 - <Image 28 28 - src={Koyeb1} 29 29 - alt="Koyeb" 30 30 - /> 31 31 - 32 32 - 33 33 - 4. In the `Image` field, enter `ghcr.io/openstatushq/checker:latest`. 34 34 - 35 35 - 36 36 - <Image 37 37 - src={Koyeb2} 38 38 - alt="Koyeb" 39 39 - /> 40 40 - 41 41 - 5. Click on the `Next` button. 42 42 - 43 43 - 6. Fill the following settings 44 44 - 45 45 - You should set the following environment variables 46 46 - - `CLOUD_PROVIDER` : Koyeb 47 47 - - `REGION` : The koyeb region where you want to deploy your checker 48 48 - - `CRON_SECRET` : A secret key to secure your endpoint to avoid unauthorized access 49 49 - 50 50 - <Image 51 51 - src={Koyeb3} 52 52 - alt="Koyeb" 53 53 - /> 54 54 - 55 55 - ## Calling your probe 56 56 - 57 57 - Once your checker is deployed, you can call it using the following command: 58 58 - 59 59 - ```bash 60 60 - curl --request POST \ 61 61 - --url https://YOUR_KOYEB_URL.koyeb.app/ping/KOYEB_REGION \ 62 62 - --header 'Authorization: Basic test' \ 63 63 - --header 'Content-Type: application/json' \ 64 64 - --data '{ 65 65 - "url": "https://www.openstatus.dev", 66 66 - "method": "GET" 67 67 - }' 68 68 - ``` 69 69 -

+78

apps/docs/src/content/docs/guides/how-to-add-svg-status-badge.mdx

··· 1 1 + --- 2 2 + title: How to Add an SVG Status Badge to your GitHub README 3 3 + --- 4 4 + 5 5 + You want to add an SVG status badge to your GitHub README? 6 6 + 7 7 + ### PNG Badge 8 8 + 9 9 + ```html 10 10 + <img src='https://[slug].openstatus.dev/badge'> 11 11 + ``` 12 12 + 13 13 + This will return a PNG image with the status of your page. It will look like this: 14 14 + <img src='https://status.openstatus.dev/badge' /> 15 15 + 16 16 + You can customize the theme by adding `?theme=dark` and the size of it by adding `?size=lg`. 17 17 + 18 18 + Supported themes: 19 19 + - `dark` 20 20 + - `light` (default) 21 21 + 22 22 + Supported sizes: 23 23 + - `sm` (default) 24 24 + - `md` 25 25 + - `lg` 26 26 + - `xl` 27 27 + 28 28 + It will display the following labels based on the current status of the status page: 29 29 + 30 30 + ``` 31 31 + Operational 32 32 + Degraded 33 33 + Outage 34 34 + Incident 35 35 + Maintenance 36 36 + Unknown 37 37 + ``` 38 38 + 39 39 + ### SVG Badge (v2) 40 40 + 41 41 + ```html 42 42 + <img src='https://[slug].openstatus.dev/badge/v2'> 43 43 + ``` 44 44 + 45 45 + This will return a PNG image with the status of your page. It will look like this: 46 46 + <img src='https://status.openstatus.dev/badge/v2' /> 47 47 + 48 48 + You can customize the theme by adding `?theme=dark`, the size of it by adding `?size=lg` and the variant `?variant=outline` - use what fits best to you! 49 49 + 50 50 + Supported themes: 51 51 + - `light` (default) 52 52 + - `dark` 53 53 + 54 54 + Supported sizes: 55 55 + - `sm` (default) 56 56 + - `md` 57 57 + - `lg` 58 58 + - `xl` 59 59 + 60 60 + Supported variants: 61 61 + - `default` (default) 62 62 + - `outline` 63 63 + 64 64 + The **outline** variant simply adds a slightly rounded border to the svg `rect`. It mainly can be used for GitHub README or Markdown where styling is not supported. 65 65 + 66 66 + Compared to the PNG badge, we let you define the `border` and `border-radius` of the SVG badge and the font is mono. 67 67 + 68 68 + It will display the following labels based on the current status of the status page: 69 69 + 70 70 + ``` 71 71 + All Systems Operational 72 72 + Degraded Performance 73 73 + Partial Outage 74 74 + Major Outage 75 75 + Ongoing Incident 76 76 + Under Maintenance 77 77 + Unknown 78 78 + ```

+63

apps/docs/src/content/docs/guides/how-to-export-metrics-to-otlp-endpoint.mdx

··· 1 1 + --- 2 2 + title: How to Export Metrics to your OTLP endpoint 3 3 + --- 4 4 + import { Image } from 'astro:assets'; 5 5 + 6 6 + import grafana from '../../../assets/guides/how-to-export-metrics-via-otel/grafana.png'; 7 7 + import newrelic from '../../../assets/guides/how-to-export-metrics-via-otel/newrelic.jpg'; 8 8 + import signoz from '../../../assets/guides/how-to-export-metrics-via-otel/signoz.jpg'; 9 9 + import honeycomb from '../../../assets/guides/how-to-export-metrics-via-otel/honeycomb.jpg'; 10 10 + 11 11 + 12 12 + At openstatus, we believe you should be able to export your metrics to your OTLP endpoint without having to change your existing monitoring platform. 13 13 + 14 14 + 15 15 + 16 16 + ## Export your metrics to your OTLP endpoint 17 17 + 18 18 + In your monitoring platform find the configuration section for metrics export. 19 19 + 20 20 + Right now we only support HTTP OTLP endpoint. 21 21 + 22 22 + In your `openstatus.yaml` file, add the following configuration: 23 23 + 24 24 + ```yaml 25 25 + openTelemetry: 26 26 + endpoint: http://your-otel-endpoint:4318/v1/metrics 27 27 + headers: 28 28 + Authorization: Bearer your-token 29 29 + ``` 30 30 + 31 31 + After every check we will send you the metrics to your monitoring stack. 32 32 + 33 33 + 34 34 + ### Grafana 35 35 + 36 36 + <Image 37 37 + src={grafana} 38 38 + alt="openstatus metrics in grafana" 39 39 + /> 40 40 + 41 41 + ### honeycomb 42 42 + 43 43 + <Image 44 44 + src={honeycomb} 45 45 + alt="openstatus metrics in honeycomb" 46 46 + /> 47 47 + 48 48 + 49 49 + ### New Relic 50 50 + 51 51 + <Image 52 52 + src={newrelic} 53 53 + alt="openstatus metrics in new-relic" 54 54 + /> 55 55 + 56 56 + 57 57 + 58 58 + ### signoz 59 59 + 60 60 + <Image 61 61 + src={signoz} 62 62 + alt="openstatus metrics in signoz" 63 63 + />

+72

apps/docs/src/content/docs/guides/how-to-use-react-widget.mdx

··· 1 1 + --- 2 2 + title: How to Use OpenStatus React Widget 3 3 + --- 4 4 + 5 5 + Install the [npm](https://www.npmjs.com/package/@openstatus/react) package: 6 6 + 7 7 + ```bash 8 8 + npm install @openstatus/react 9 9 + ``` 10 10 + 11 11 + ## React Server Component 12 12 + 13 13 + ```tsx 14 14 + import { StatusWidget } from "@openstatus/react"; 15 15 + 16 16 + export function Page() { 17 17 + return <StatusWidget slug="status" />; 18 18 + } 19 19 + ``` 20 20 + 21 21 + It will automatically attach the slug to the href to allow the user to open a 22 22 + new tab on click to `https://slug.openstatus.dev`. If you want to redirect him 23 23 + to a specific page, use the `href` property, like so: 24 24 + 25 25 + ```tsx 26 26 + <StatusWidget slug="documenso" href="https://status.documenso.com" /> 27 27 + ``` 28 28 + 29 29 + > `StatusWidget` is an **async function** and will only work with RSC. Using it 30 30 + > within a dead simple React App will not work. 31 31 + 32 32 + ### Styling 33 33 + 34 34 + #### With tailwindcss 35 35 + 36 36 + ```ts 37 37 + // tailwind.config.js 38 38 + module.exports = { 39 39 + content: [ 40 40 + "./app/**/*.{tsx,ts,mdx,md}", 41 41 + "./node_modules/@openstatus/react/**/*.{js,ts,jsx,tsx}", 42 42 + ], 43 43 + theme: { 44 44 + extend: {}, 45 45 + }, 46 46 + plugins: [], 47 47 + }; 48 48 + ``` 49 49 + 50 50 + #### Without tailwindcss 51 51 + 52 52 + ```tsx 53 53 + // app/layout.tsx 54 54 + import "@openstatus/react/dist/styles.css"; 55 55 + ``` 56 56 + 57 57 + ## Typed fetch function 58 58 + 59 59 + ```tsx 60 60 + import { getStatus } from "@openstatus/react"; 61 61 + 62 62 + // React Server Component 63 63 + async function CustomStatusWidget() { 64 64 + const res = await getStatus("slug"); 65 65 + // ^StatusResponse = { status: Status } 66 66 + 67 67 + const { status } = res; 68 68 + // ^Status = "unknown" | "operational" | "degraded_performance" | "partial_outage" | "major_outage" | "under_maintenance" | "incident" 69 69 + 70 70 + return <div>{/* customize */}</div>; 71 71 + } 72 72 + ```

-17

apps/docs/src/content/docs/guides/introduction.mdx

··· 1 1 - --- 2 2 - title: Introduction 3 3 - description: Guides to get started with OpenStatus 4 4 - sidebar: 5 5 - label: Introduction 6 6 - order: 1 7 7 - --- 8 8 - 9 9 - Here's some content for the getting started with OpenStatus. 10 10 - 11 11 - - [How to deploy your own probe to Koyeb](/guides/how-deploy-checker-koyeb/) 12 12 - 13 13 - - [Deploy your own Status Page to Cloudflare Pages](/guides/how-deploy-status-page-cf-pages) 14 14 - 15 15 - - [How to monitor your MCP Server using OpenStatus](/guides/how-to-monitor-mcp-server/) 16 16 - 17 17 - - [How to run synthetic tests in your GitHub Actions](/guides/how-to-run-synthetic-test-github-action/)

+10 -21

apps/docs/src/content/docs/index.mdx

··· 5 5 topic: docs 6 6 next: false 7 7 hero: 8 8 - title: Welcome to OpenStatus 9 9 - tagline: Explore our documentation to get started with OpenStatus and start monitoring your services. 8 8 + title: Welcome to openstatus 9 9 + tagline: Explore our documentation to get started with openstatus and start monitoring your services. 10 10 --- 11 11 12 12 import { Card, CardGrid, LinkCard } from '@astrojs/starlight/components'; 13 13 import "../../custom.css" 14 14 15 15 - ### What is OpenStatus? 15 15 + ### What is openstatus? 16 16 17 17 - [OpenStatus](https://www.openstatus.dev) is an open-source synthetic monitoring tool that helps you monitor the availability and performance of your website, API, servers, or anything that can be monitored from various locations around the world. 17 17 + [openstatus](https://www.openstatus.dev) is an open-source synthetic monitoring tool that helps you monitor the availability and performance of your website, API, servers, or anything that can be monitored from various locations around the world. 18 18 19 19 - We also provide beautiful [status pages](/status-page/overview) to keep your users informed about the status of your services. 19 19 + We also provide [status pages](/tutorial/how-to-create-status-page) to keep your users informed about the status of your services. 20 20 21 21 #### Monitoring as Code 22 22 23 23 - We provide a [CLI](/cli/getting-started) to manage your monitors as code. 23 23 + We provide a [CLI](/tutorial/get-started-with-openstatus-cli) to manage your monitors as code. 24 24 25 25 ### New to OpenStatus? 26 26 27 27 28 28 <CardGrid > 29 29 - <Card title="Synthetic Monitoring" icon="open-book"> 30 30 - Learn how to <a href="/monitoring/create-monitor">create</a> your first monitor with OpenStatus. 31 31 - </Card> 32 32 - <Card title="Guides " icon="rocket"> 33 33 - Read our <a href="guides/introduction/">guides</a> to discover what you can do with OpenStatus 34 34 - </Card> 35 35 - <Card title="CLI" icon="seti:shell"> 36 36 - Learn more about our [CLI](/cli/getting-started) to manage and run your synthetic check. 37 37 - </Card> 38 38 - <Card title="API Reference" icon="puzzle"> 39 39 - Use our <a href="https://api.openstatus.dev/v1">API</a> to build amazing things on top of OpenStatus 40 40 - </Card> 41 41 - <Card title="Open Source" icon="seti:github"> 42 42 - Checkout our [GitHub repository](https://www.github.com/openstatushq/openstatus) to contribute or report issues. 43 43 - </Card> 29 29 + <LinkCard title="Concepts" href="/concept/getting-started/" description="Read about the concept behind OpenStatus" /> 30 30 + <LinkCard title="Tutorials" href="/tutorial/getting-started/" description="Read our tutorials to learn how to use OpenStatus" /> 31 31 + <LinkCard title="Guides" href="/guides/getting-started/" description="Some useful guides about openstatus" /> 32 32 + <LinkCard title="Help" href="/help/support/" description="Need help?" /> 44 33 </CardGrid> 45 34 46 35

+5 -29

apps/docs/src/content/docs/monitoring/create-monitor.mdx apps/docs/src/content/docs/tutorial/how-to-create-monitor.mdx

··· 1 1 --- 2 2 - title: Creating Your First Monitor 2 2 + title: Create Your First Monitor 3 3 description: "How to create your first monitor with OpenStatus" 4 4 --- 5 5 6 6 import { Image } from 'astro:assets'; 7 7 import { Aside, CardGrid, LinkCard } from '@astrojs/starlight/components'; 8 8 - import monitorOverview from '../../../assets/monitor/create-monitor/monitor-overview.png'; 9 9 - import createMonitor from '../../../assets/monitor/create-monitor/create-monitor-1.png'; 10 10 - import createMonitor2 from '../../../assets/monitor/create-monitor/create-monitor-2.png'; 8 8 + import monitorOverview from '../../../assets/tutorial/create-monitor/monitor-overview.png'; 9 9 + import createMonitor from '../../../assets/tutorial/create-monitor/create-monitor-1.png'; 10 10 + import createMonitor2 from '../../../assets/tutorial/create-monitor/create-monitor-2.png'; 11 11 12 12 import { ShowcaseYouTube } from 'starlight-showcases' 13 13 14 14 15 15 16 16 - This guide will walk you through the process of creating your first monitor, your automated watchdog for your services. A monitor periodically checks your endpoints to ensure they are available, performant, and returning the correct data. Think of it as a `curl` command that runs 24/7, providing continuous insights into the health of your application. 16 16 + This tutorial will walk you through the process of creating your first monitor, your automated watchdog for your services. A monitor periodically checks your endpoints to ensure they are available, performant, and returning the correct data. Think of it as a `curl` command that runs 24/7, providing continuous insights into the health of your application. 17 17 18 18 19 19 ## Get Started in 1 Minute ··· 87 87 Heads Up: We've got your User-Agent covered! 88 88 OpenStatus automatically includes the `"User-Agent": "OpenStatus/1.0"` header in every request. This makes it easy to identify and filter out our monitoring traffic from your server logs or analytics. 89 89 90 90 - 91 91 - 92 92 - ## Fine-Tuning Your Monitor ⚙️ 93 93 - 94 94 - Once you've configured the basics, you can further refine your monitor's behavior with these advanced options: 95 95 - 96 96 - <CardGrid> 97 97 - <LinkCard 98 98 - title="Assertions" 99 99 - href="/monitoring/customization/assertions" 100 100 - /> 101 101 - <LinkCard 102 102 - title="Frequency" 103 103 - href="/monitoring/customization/frequency" 104 104 - /> 105 105 - <LinkCard 106 106 - title="Locations" 107 107 - href="/monitoring/customization/locations" 108 108 - /> 109 109 - <LinkCard 110 110 - title="Timing" 111 111 - href="/monitoring/customization/timing" 112 112 - /> 113 113 - </CardGrid> 114 90 115 91 116 92

+4

apps/docs/src/content/docs/reference.mdx

··· 1 1 + --- 2 2 + title: About this project 3 3 + description: Learn more about the project I’m working on. 4 4 + ---

+144

apps/docs/src/content/docs/reference/http-monitor.mdx

··· 1 1 + --- 2 2 + title: HTTP Monitor 3 3 + --- 4 4 + 5 5 + An HTTP Monitor is a component that allows you to monitor the status of HTTP endpoints. It can be used to monitor the status of a website, an API, or any other HTTP endpoint. 6 6 + 7 7 + ## Configuration 8 8 + 9 9 + ### URL 10 10 + 11 11 + The url of the HTTP endpoint you want to monitor e.g `https://openstat.us` 12 12 + 13 13 + ### Methods 14 14 + 15 15 + The HTTP method you want to use to monitor the endpoint. 16 16 + - `GET` 17 17 + - `POST` 18 18 + - `PUT` 19 19 + - `DELETE` 20 20 + - `HEAD` 21 21 + - `OPTIONS` 22 22 + - `PATCH` 23 23 + - `TRACE` 24 24 + 25 25 + ### Body 26 26 + 27 27 + The body of the HTTP request you want to send to the endpoint. You use binary data if the content type is `application/octet-stream`. 28 28 + Example: 29 29 + - `{ "key": "value" }` 30 30 + - `data:image/jpeg;base64,/9j...` 31 31 + ### Headers 32 32 + 33 33 + The headers you want to send with the HTTP request 34 34 + 35 35 + Example: 36 36 + - `"Content-Type": "application/json"` 37 37 + - `'Content-Type: application/octet-stream'` 38 38 + 39 39 + ### Regions 40 40 + 41 41 + The regions where we are triggering the HTTP request. 42 42 + 43 43 + __Africa__ 44 44 + 45 45 + - Johannesburg, South Africa 🇿🇦 (free) 46 46 + 47 47 + __Asia__ 48 48 + 49 49 + - Hong Kong, Hong Kong 🇭🇰 (free) 50 50 + - Mumbai, India 🇮🇳 51 51 + - Singapore, Singapore 🇸🇬 52 52 + - Tokyo, Japan 🇯🇵 53 53 + 54 54 + __Europe__ 55 55 + 56 56 + - Amsterdam, Netherlands 🇳🇱 (free) 57 57 + - Bucharest, Romania 🇷🇴 58 58 + - Frankfurt, Germany 🇩🇪 59 59 + - London, United Kingdom 🇬🇧 60 60 + - Madrid, Spain 🇪🇸 61 61 + - Paris, France 🇫🇷 62 62 + - Stockholm, Sweden 🇸🇪 63 63 + - Warsaw, Poland 🇵🇱 64 64 + 65 65 + __North America__ 66 66 + 67 67 + - Ashburn, Virginia, USA 🇺🇸 (free) 68 68 + - Atlanta, Georgia, USA 🇺🇸 69 69 + - Boston, Massachusetts, USA 🇺🇸 70 70 + - Chicago, Illinois, USA 🇺🇸 71 71 + - Dallas, Texas, USA 🇺🇸 72 72 + - Denver, Colorado, USA 🇺🇸 73 73 + - Guadalajara, Mexico 🇲🇽 74 74 + - Los Angeles, California, USA 🇺🇸 75 75 + - Miami, Florida, USA 🇺🇸 76 76 + - Montreal, Canada 🇨🇦 77 77 + - Phoenix, Arizona, USA 🇺🇸 78 78 + - Queretaro, Mexico 🇲🇽 79 79 + - Seattle, Washington, USA 🇺🇸 80 80 + - San Jose, California, USA 🇺🇸 81 81 + - Toronto, Canada 🇨🇦 82 82 + 83 83 + __South America__ 84 84 + 85 85 + - Bogota, Colombia 🇨🇴 86 86 + - Buenos Aires, Argentina 🇦🇷 87 87 + - Rio de Janeiro, Brazil 🇧🇷 88 88 + - Sao Paulo, Brazil 🇧🇷 (free) 89 89 + - Santiago, Chile 🇨🇱 90 90 + 91 91 + __Oceania__ 92 92 + 93 93 + - Sydney, Australia 🇦🇺 (free) 94 94 + 95 95 + ### Frequency 96 96 + 97 97 + The check interval, we support the following frequencies: 98 98 + - 30 seconds 99 99 + - 1 minute 100 100 + - 5 minutes 101 101 + - 10 minutes 102 102 + - 30 minutes 103 103 + - 1 hour 104 104 + 105 105 + ### Response Time Thresholds 106 106 + #### Timeout 107 107 + The timeout for the HTTP request, default is `45 seconds` 108 108 + #### Degraded 109 109 + The duration for which the HTTP request is considered degraded. 110 110 + 111 111 + ### Retry 112 112 + The number of retries for the HTTP request. For example: `3` 113 113 + 114 114 + ### Assertions 115 115 + #### Body assertions 116 116 + Validate the body of the response. The comparisons are: 117 117 + - Contains 118 118 + - Not Contains 119 119 + - Equal 120 120 + - Not Equal 121 121 + - Empty 122 122 + 123 123 + #### Status code assertions 124 124 + Validate the status code of the response. The comparisons are: 125 125 + - Equal 126 126 + - Not Equal 127 127 + - Greater Than 128 128 + - Greater Than or Equal 129 129 + - Less Than 130 130 + - Less Than or Equal 131 131 + 132 132 + #### Headers assertions 133 133 + Validate the headers of the reponse. The comparisons are: 134 134 + - Contains 135 135 + - Not Contains 136 136 + - Equal 137 137 + - Not Equal 138 138 + - Empty 139 139 + 140 140 + ### OpenTelemetry 141 141 + #### OTPL Endpoint 142 142 + The endpoint we use to export the metrics. We only support HTTP endpoint. 143 143 + #### OTLP Headers 144 144 + The headers we use to export the metrics to your otlp endpoint.

+7

apps/docs/src/content/docs/reference/incident.mdx

··· 1 1 + --- 2 2 + title: Incident 3 3 + --- 4 4 + 5 5 + An incident is a problem related to a monitor. They are created automatically when a monitor fails. 6 6 + 7 7 + At least 50% must have failed to trigger the incident.

+120

apps/docs/src/content/docs/reference/notification.mdx

··· 1 1 + --- 2 2 + title: Notification 3 3 + --- 4 4 + 5 5 + A notification is a channel that is used to send alerts when your monitor status changes. By default no notifications are created in your workspace. 6 6 + 7 7 + 8 8 + ## Notification Channels: 9 9 + 10 10 + ### Slack 11 11 + 12 12 + Require a [Slack incoming webhook](https://api.slack.com/incoming-webhooks) 13 13 + 14 14 + ### Email 15 15 + 16 16 + Require an email address 17 17 + 18 18 + ### Discord 19 19 + 20 20 + Require a [discord webhook](https://support.discord.com/hc/en-us/articles/228383668 21 21 + ) e.g. `https://discordapp.com/api/webhooks/123456789012345678/abcdefghijklmnopqrstuvwxyz1234567890` 22 22 + 23 23 + ### SMS 24 24 + 25 25 + Require a phone number 26 26 + 27 27 + ### Webhook 28 28 + 29 29 + - URL (require) 30 30 + - Headers (optional) 31 31 + 32 32 + #### Notification Payloads 33 33 + 34 34 + ##### Payload for Monitor Recovery 35 35 + 36 36 + ```json 37 37 + { 38 38 + "monitor": { 39 39 + "id": 1, 40 40 + "name": "test", 41 41 + "url": "http://openstat.us" 42 42 + }, 43 43 + "cronTimestamp": 1744023705307, 44 44 + "status": "recovered", 45 45 + "statusCode": 200, 46 46 + "latency": 1337 47 47 + } 48 48 + ``` 49 49 + 50 50 + 51 51 + Fields Explanation: 52 52 + - monitor: Contains details about the monitor. 53 53 + - id: Unique identifier for the monitor. 54 54 + - name: Name of the monitor. 55 55 + - url: The URL being monitored. 56 56 + - cronTimestamp: The timestamp when the check was executed, in milliseconds since epoch. 57 57 + - status: Indicates the current status of the monitor (in this case, "recovered"). 58 58 + - statusCode: The HTTP status code returned by the monitored service. 59 59 + - latency: The time taken to complete the check, in milliseconds. 60 60 + 61 61 + 62 62 + ##### Payload for Monitor Failure 63 63 + 64 64 + ```json 65 65 + { 66 66 + "monitor": { 67 67 + "id": 1, 68 68 + "name": "test", 69 69 + "url": "http://openstat.us" 70 70 + }, 71 71 + "cronTimestamp": 1744023705307, 72 72 + "status": "error", 73 73 + "errorMessage": "Connection refused" 74 74 + } 75 75 + ``` 76 76 + 77 77 + Fields Explanation: 78 78 + 79 79 + - monitor: Contains details about the monitor. 80 80 + - id: Unique identifier for the monitor. 81 81 + - name: Name of the monitor. 82 82 + - url: The URL being monitored. 83 83 + - cronTimestamp: The timestamp when the check was executed, in milliseconds since epoch. 84 84 + - status: Indicates the current status of the monitor (in this case, "error"). 85 85 + - errorMessage: A description of the error encountered during the check. 86 86 + 87 87 + 88 88 + #### Zod Schema 89 89 + 90 90 + 91 91 + ```ts 92 92 + import { z } from "zod"; 93 93 + 94 94 + export const PayloadSchema = z.object({ 95 95 + monitor: z.object({ 96 96 + id: z.number(), 97 97 + name: z.string(), 98 98 + url: z.string(), 99 99 + }), 100 100 + cronTimestamp: z.number(), 101 101 + status: z.enum(["degraded", "error", "recovered"]), 102 102 + statusCode: z.number().optional(), 103 103 + latency: z.number().optional(), 104 104 + errorMessage: z.string().optional(), 105 105 + }); 106 106 + ```` 107 107 + 108 108 + ### OpsGenie 109 109 + 110 110 + - API key from OpsGenie (required) 111 111 + 112 112 + ### PagerDuty 113 113 + 114 114 + Follow the step in PagerDuty workflow 115 115 + 116 116 + ### Ntfy 117 117 + 118 118 + - Ntfy topic (required) 119 119 + - Custom server url (optional) 120 120 + - bearer token (optional)

+23

apps/docs/src/content/docs/reference/status-page.mdx

··· 1 1 + --- 2 2 + title: Status Page 3 3 + --- 4 4 + 5 5 + A status page is a web page that displays the current status of a service or system. 6 6 + 7 7 + ## Configuration 8 8 + 9 9 + ### Slug 10 10 + 11 11 + You slug is a unique identifier for your status page. It is used in the URL of your status page. e.g `status` => `https://status.openstatus.dev` 12 12 + 13 13 + ### Custom Domain 14 14 + 15 15 + You can configure a custom domain for your status page. e.g `status.example.com` => `https://status.example.com` 16 16 + 17 17 + ### Password 18 18 + 19 19 + You can add a password for your status page. 20 20 + 21 21 + ### Favicon 22 22 + 23 23 + You can add a favicon for your status page.

+25

apps/docs/src/content/docs/reference/status-report.mdx

··· 1 1 + --- 2 2 + title: Status Report 3 3 + --- 4 4 + 5 5 + A status report is an event of an incident. 6 6 + 7 7 + 8 8 + ## Configuration 9 9 + 10 10 + ### Status 11 11 + 12 12 + The status of an incident can be: 13 13 + 14 14 + - `investigating` 15 15 + - `identified` 16 16 + - `monitoring` 17 17 + - `resolved` 18 18 + 19 19 + ### Date 20 20 + 21 21 + The date of the status report 22 22 + 23 23 + ### Message 24 24 + 25 25 + The message of the status report

+7

apps/docs/src/content/docs/reference/subscriber.mdx

··· 1 1 + --- 2 2 + title: Subscriber 3 3 + --- 4 4 + 5 5 + A subscriber is a user who receives notifications about incidents. 6 6 + 7 7 + They have to subscribe to update from your status page.

+93

apps/docs/src/content/docs/reference/tcp-monitor.mdx

··· 1 1 + --- 2 2 + title: TCP Monitor 3 3 + --- 4 4 + 5 5 + 6 6 + A TCP Monitor is a component that allows you to monitor the status of your services. 7 7 + 8 8 + ## Configuration 9 9 + 10 10 + ### URI 11 11 + 12 12 + The url of the endpoint you want to monitor e.g `openstat.us:443` 13 13 + 14 14 + ### Regions 15 15 + 16 16 + The regions where we are triggering the HTTP request. 17 17 + 18 18 + __Africa__ 19 19 + 20 20 + - Johannesburg, South Africa 🇿🇦 (free) 21 21 + 22 22 + __Asia__ 23 23 + 24 24 + - Hong Kong, Hong Kong 🇭🇰 (free) 25 25 + - Mumbai, India 🇮🇳 26 26 + - Singapore, Singapore 🇸🇬 27 27 + - Tokyo, Japan 🇯🇵 28 28 + 29 29 + __Europe__ 30 30 + 31 31 + - Amsterdam, Netherlands 🇳🇱 (free) 32 32 + - Bucharest, Romania 🇷🇴 33 33 + - Frankfurt, Germany 🇩🇪 34 34 + - London, United Kingdom 🇬🇧 35 35 + - Madrid, Spain 🇪🇸 36 36 + - Paris, France 🇫🇷 37 37 + - Stockholm, Sweden 🇸🇪 38 38 + - Warsaw, Poland 🇵🇱 39 39 + 40 40 + __North America__ 41 41 + 42 42 + - Ashburn, Virginia, USA 🇺🇸 (free) 43 43 + - Atlanta, Georgia, USA 🇺🇸 44 44 + - Boston, Massachusetts, USA 🇺🇸 45 45 + - Chicago, Illinois, USA 🇺🇸 46 46 + - Dallas, Texas, USA 🇺🇸 47 47 + - Denver, Colorado, USA 🇺🇸 48 48 + - Guadalajara, Mexico 🇲🇽 49 49 + - Los Angeles, California, USA 🇺🇸 50 50 + - Miami, Florida, USA 🇺🇸 51 51 + - Montreal, Canada 🇨🇦 52 52 + - Phoenix, Arizona, USA 🇺🇸 53 53 + - Queretaro, Mexico 🇲🇽 54 54 + - Seattle, Washington, USA 🇺🇸 55 55 + - San Jose, California, USA 🇺🇸 56 56 + - Toronto, Canada 🇨🇦 57 57 + 58 58 + __South America__ 59 59 + 60 60 + - Bogota, Colombia 🇨🇴 61 61 + - Buenos Aires, Argentina 🇦🇷 62 62 + - Rio de Janeiro, Brazil 🇧🇷 63 63 + - Sao Paulo, Brazil 🇧🇷 (free) 64 64 + - Santiago, Chile 🇨🇱 65 65 + 66 66 + __Oceania__ 67 67 + 68 68 + - Sydney, Australia 🇦🇺 (free) 69 69 + 70 70 + ### Frequency 71 71 + 72 72 + The check interval, we support the following frequencies: 73 73 + - 30 seconds 74 74 + - 1 minute 75 75 + - 5 minutes 76 76 + - 10 minutes 77 77 + - 30 minutes 78 78 + - 1 hour 79 79 + 80 80 + ### Response Time Thresholds 81 81 + #### Timeout 82 82 + The timeout for the HTTP request, default: `45 seconds` 83 83 + #### Degraded 84 84 + The duration for which the HTTP request is considered degraded. 85 85 + 86 86 + ### Retry 87 87 + The number of retries for the HTTP request. Default: `3` 88 88 + 89 89 + ### OpenTelemetry 90 90 + #### OTPL Endpoint 91 91 + The endpoint we use to export the metrics. We only support HTTP endpoint. 92 92 + #### OTLP Headers 93 93 + The headers we use to export the metrics to your otlp endpoint.

+27

apps/docs/src/content/docs/reference/terraform.mdx

··· 1 1 + --- 2 2 + title: Terraform Provider 3 3 + description: 4 4 + "Use OpenStatus Terraform provider to manage your monitors and status page." 5 5 + --- 6 6 + 7 7 + Here you can find the official OpenStatus Terraform provider. This provider 8 8 + allows you to manage your monitors and status page using Terraform. 9 9 + 10 10 + https://registry.terraform.io/providers/openstatusHQ/openstatus/latest 11 11 + 12 12 + ## Usage 13 13 + 14 14 + ``` 15 15 + provider "openstatus" { 16 16 + openstatus_api_token= "YOUR_API_TOKEN" 17 17 + } 18 18 + 19 19 + resource "openstatus_monitor" "my_monitor" { 20 20 + url = "https://www.openstatus.dev" 21 21 + regions= ["iad", "jnb"] 22 22 + periodicity = "10m" 23 23 + name = "test-monitor" 24 24 + active = true 25 25 + description = "This is a test monitor" 26 26 + } 27 27 + ```

+2 -22

apps/docs/src/content/docs/status-page/create-status-page.mdx

··· 1 1 --- 2 2 - title: How to create a status page? 3 3 - description: "How to create a status page in OpenStatus" 2 2 + title: About this project 3 3 + description: Learn more about the project I’m working on. 4 4 --- 5 5 - 6 6 - import { Image } from 'astro:assets'; 7 7 - 8 8 - import StatusPageEmpty from '../../../assets/status-page/status-page-empty.png'; 9 9 - 10 10 - When you create your first status page, you will see an empty page. 11 11 - 12 12 - In order to create your status page, you need to create at least one monitor. 13 13 - 14 14 - <Image 15 15 - src={StatusPageEmpty} 16 16 - alt="Create your status page" 17 17 - /> 18 18 - 19 19 - 20 20 - Then you need to give your status page a name and choose a slug. 21 21 - 22 22 - Your status page will be available at `https://<slug>.openstatus.dev/`. 23 23 - 24 24 - You can also set a [custom domain](/status-page/advanced/custom-domain) for your status page.

+61

apps/docs/src/content/docs/tutorial/get-started-with-openstatus-cli.mdx

··· 1 1 + --- 2 2 + title: Get Started with openstatus CLI 3 3 + --- 4 4 + 5 5 + import { Image } from 'astro:assets'; 6 6 + import CLI from '../../../assets/tutorial/get-started-with-openstatus-cli/CLI.png'; 7 7 + 8 8 + <Image 9 9 + src={CLI} 10 10 + alt="openstatus CLI" 11 11 + /> 12 12 + 13 13 + ## Installation 14 14 + 15 15 + 16 16 + Install the OpenStatus CLI to set up your monitors straight in your code. 17 17 + 18 18 + ### OS X 19 19 + ```bash 20 20 + brew install openstatusHQ/cli/openstatus --cask 21 21 + ``` 22 22 + or 23 23 + 24 24 + ```bash 25 25 + curl -sSL instl.sh/openstatushq/cli/macos | bash 26 26 + ``` 27 27 + 28 28 + ### Linux 29 29 + ```bash 30 30 + curl -sSL instl.sh/openstatushq/cli/linux | bash 31 31 + ``` 32 32 + 33 33 + ### Windows 34 34 + 35 35 + ```bash 36 36 + iwr instl.sh/openstatushq/cli/windows | iex 37 37 + ``` 38 38 + 39 39 + ## Add API Key 40 40 + 41 41 + Create an API key in your workspace settings. 42 42 + 43 43 + ```bash 44 44 + export OPENSTATUS_API_TOKEN=<your-api-token> 45 45 + ``` 46 46 + 47 47 + ## Import Monitors 48 48 + 49 49 + Import monitors from your workspace to a YAML file. 50 50 + 51 51 + ```bash 52 52 + openstatus monitors import 53 53 + ``` 54 54 + 55 55 + ### Manage Monitors 56 56 + 57 57 + Add, remove, or update monitors from a YAML file and apply your changes. 58 58 + 59 59 + ```bash 60 60 + openstatus monitors apply 61 61 + ```

+9

apps/docs/src/content/docs/tutorial/getting-started.mdx

··· 1 1 + --- 2 2 + title: Getting Started 3 3 + --- 4 4 + 5 5 + Here are some tutorials to help you get started with OpenStatus: 6 6 + 7 7 + - [How to create your first monitor with OpenStatus](/tutorial/how-to-create-monitor) 8 8 + - [How to create a status page?](/tutorial/how-to-create-status-page) 9 9 + - [Get Started with openstatus CLI](/tutorial/get-started-with-openstatus-cli)

+50

apps/docs/src/content/docs/tutorial/how-to-create-status-page.mdx

··· 1 1 + --- 2 2 + title: How to create a status page? 3 3 + description: "How to create a status page in OpenStatus" 4 4 + --- 5 5 + 6 6 + import { Image } from 'astro:assets'; 7 7 + 8 8 + import CreateStatusPage1 from '../../../assets/tutorial/create-status-page/create-status-page-1.png'; 9 9 + 10 10 + import CreateStatusPage2 from '../../../assets/tutorial/create-status-page/create-status-page-2.png'; 11 11 + 12 12 + 13 13 + 14 14 + This tutorial will guide you through the process of creating a status page in openstatus. A status page is a web page that displays the status of your services. 15 15 + 16 16 + ## Get started 17 17 + 18 18 + ### 1. Create the status page 19 19 + 20 20 + Navigate to the **Status Pages** page from the sidebar and click the **Create Status Page** button. This will open a new configuration screen. 21 21 + 22 22 + <Image 23 23 + src={CreateStatusPage1} 24 24 + alt="Create your status page" 25 25 + /> 26 26 + 27 27 + 28 28 + ### 2. Configure the status page 29 29 + 30 30 + After creating the status page, you can configure it 31 31 + 32 32 + 33 33 + 34 34 + <Image 35 35 + src={CreateStatusPage2} 36 36 + alt="Configure your status page" 37 37 + /> 38 38 + 39 39 + #### Monitors 40 40 + 41 41 + You need to add monitors to your status page. Monitors are used to check the status of your services. 42 42 + 43 43 + #### Custom domain 44 44 + 45 45 + You can add a Custom Domain to your status page. Custom domains allow you to use your own domain name instead of the default domain name provided by OpenStatus. 46 46 + 47 47 + 48 48 + #### Password Protection 49 49 + 50 50 + You can add password protection to your status page. Password protection allows you to restrict access to your status page to only authorized users.

+4

apps/docs/src/content/docs/tutorials.mdx

··· 1 1 + --- 2 2 + title: Tutorials 3 3 + description: Learn more about the project I’m working on. 4 4 + ---