Create your first monitor

This tutorial walks you through creating an HTTP availability monitor on your personal team, linking one assertion, and reading the first check result. Expect about 10 minutes.

Onboarding uses this same path when your primary job is uptime monitoring or a status page. The first run is forced immediately so you do not wait for the Free-plan interval.

Prerequisites

• A Crystade account signed in with Google or GitHub
• A public HTTPS URL you are allowed to probe (for example https://example.com)
• Your personal team selected in the team switcher

Step 1: Create an HTTP monitor

For website owners

1. Open Monitors on your personal team and choose Create a monitor (or New Monitor).

   

2. Name the monitor after the site or service, for example Marketing site.

   

3. Choose the HTTP protocol and paste the URL to check.

4. Leave the interval at the plan default. Free teams cannot go faster than every 5 minutes. This tutorial still shows a result immediately because Crystade runs the first check without waiting for that interval.

5. Save the monitor.

For developers

1. Open Monitors and create a monitor with protocol HTTP.

2. Set the URL, optional headers (max 20), optional text body (max 64 KB), redirect-follow limit (max 10), and connection timeout (max 5 minutes).

3. Pick probe locations from europe-north1, us-west1, asia-southeast1, and australia-southeast1. The number of locations is plan-gated.

4. For TCP, TLS (Starter and Standard), or Minecraft instead of HTTP, see Create an availability monitor. Skip UDP; it is not available.

5. Save the monitor. Definition updates take effect within 5 minutes. The onboarding first run uses the saved definition immediately.

Private, loopback, and link-local destinations are rejected.

Step 2: Link an assertion

A monitor records probe results. An assertion decides whether those results are healthy or a failure, and can open an incident when the failure pattern holds.

1. Open the new monitor and link an assertion from your team’s library. Create one if the library is empty. On create, the New Monitor wizard includes an Assertions step after Active monitoring.

   

2. Keep the default hysteresis for this tutorial: open an incident on 3 failed checks out of 5, and close it after 5 consecutive successes.

3. Free teams can link 1 assertion per monitor. That is enough for this first win.

Note

The first-win wait continues until check logs are terminal and linked assertion runs are available, or until a short wait limit is reached. If the wait times out, the monitor already exists and later checks still run.

Step 3: Read the first check result

1. Stay on the monitor until the forced first run completes, or open the check log from the monitor page.

2. Confirm the request URL, location, timing (DNS, first byte, round trip), and whether the assertion run is healthy or failed.

3. If the check failed, confirm the URL is public and responds to Crystade’s regions, then save and wait for the next check.

Next steps

Create an availability monitor HTTP, TCP, TLS, and Minecraft options, intervals, and regions.

Configure assertions Link assertions and tune when incidents open and close.

Send Discord, Slack, Telegram, or Zalo alerts Notify a channel when monitors fail or recover.

Publish a status page Show monitor uptime and published incidents to users.