Start monitoring your first service

Create and protect your account

1. 1

   Create an account

   Register with an email address you control and choose a unique password.

2. 2

   Confirm your email

   Open the verification message before creating monitors or changing operational settings.

3. 3

   Enable two-step verification

   Add an authenticator from the Security page and store the recovery codes somewhere safe.

Add the first monitor

1. 1

   Choose what to monitor

   Start with the main website or health endpoint that best represents whether the service is usable.

2. 2

   Set the expected result

   Choose the monitor type, public destination, timeout, and success condition. Use retries only when they reduce short-lived false alarms.

3. 3

   Choose an interval

   One minute is the shortest interval. A longer interval is often enough for less critical services and reduces traffic to the destination.

4. 4

   Run the access check

   Verify the destination before relying on the monitor. Resolve certificate, DNS, firewall, or response-rule problems shown by the result.

Allow monitoring through your firewall

A firewall or security service may reject checks even when the website works for visitors. If repeated requests cannot reach the destination, FLUX Monitoring can pause the monitor and show the addresses that need to be allowed.

Add only the addresses shown in your dashboard to the destination firewall. Then use Verify and resume monitoring. Do not disable the firewall or allow all traffic as a shortcut.

Send alerts to the right place

1. 1

   Add a notification channel

   Choose email or an available messaging or webhook channel, then send a test message.

2. 2

   Set the alert policy

   Choose the incident severity and events that should notify the team. Avoid sending every low-value update to everyone.

3. 3

   Add escalation when needed

   For critical services, route unresolved incidents to the next available responder.

Keep users informed

Create a status page, add the services users care about, and publish only the incidents or maintenance updates that should be public. Choose public, password-protected, or private access based on the audience.

Use plain service names and concise incident updates. Do not expose internal addresses, credentials, customer records, or debugging details.

A dependable first-week checklist

• Review the first results and adjust a success rule that is too strict or too broad.
• Confirm that an alert reaches the intended person and recovery messages are useful.
• Create a short maintenance window before planned work.
• Add a second team member instead of sharing credentials.
• Review session and API-token activity from Security settings.
• Share the public status page with the people who need it.