Alerts, Rules, Security Actions & Staff Roles

This chapter explains WatchTower’s event review and security workflows. It is written carefully because land actions can affect customers, renters, guests, and staff. The system should help owners respond to problems without overstating what the scripts can prove or do.

Alerts

An alert is an owner-important event. Not every data update should become an alert. A land snapshot, scanner batch, or heartbeat is normal telemetry. An alert should mean something needs review, attention, or a decision.

Common alerts include:

• Terminal offline or stale
• Location over subscription limit
• Low script memory
• HTTP queue repeatedly dropping payloads
• Region lag or health warning
• Watched avatar seen
• Payment mismatch
• Security action failed or pending
• Discord alert delivery failed
• Chat Relay queue full
• Adult Access Gate configuration problem
• Support ticket waiting for owner/staff

Alert severity

Suggested severity levels:

Rules

Rules are conditions that create alerts or request actions. They should be easy to understand. Owners should know what condition triggers the rule, what the rule does, and whether staff review is required.

Example rule types:

• If terminal is stale for more than X minutes, create an alert.
• If watched avatar is seen, create an alert.
• If region lag score drops below X, create an alert.
• If Payment Station receives an unknown amount, create a review item.
• If scanner data is stale, warn owner before showing outdated people counts.
• If adult gate detects a blocked state, create an owner alert.

Rules should avoid runaway behavior. A rule should not send dozens of messages every minute. It should rate-limit repeated alerts, group repeats into summaries when possible, and allow owners to mute or resolve an alert.

Security Actions

Security Actions are dashboard-driven requests such as warn, eject, ban, or unban. The Security Worker polls the website for commands, attempts the action using Second Life LSL functions, and reports the result back to the dashboard.

Important wording:

• **Warn** means the object sent an instant message to the avatar UUID.
• **Eject attempted** means the object called the land eject function.
• **Ban attempted** means the object called the land ban function and may also attempt eject.
• **Unban attempted** means the object called the land unban function.

The dashboard should not say an eject or ban is guaranteed unless the system can verify the result. In many cases, Second Life land permissions decide whether the action actually worked.

Security workflow

Recommended workflow for owner/staff review:

1. Alert is created.
2. Owner or authorized staff opens the alert.
3. Dashboard shows location, avatar, rule, evidence, and suggested action.
4. Staff chooses warn/eject/ban/unban only if their role allows it.
5. Command is queued for the Security Worker.
6. Security Worker polls, attempts action, and reports result.
7. Dashboard records audit log with who requested it, when, and what result was reported.

Staff Roles

Staff Roles should control who can see and do things in the dashboard. A rental manager may need ticket access but not billing access. A club moderator may need security actions but not plan changes. A developer may need API logs but not customer billing controls.

Suggested roles:

Permission matrix recommendation

Safety requirements

Security tools should never hide important limits. If an action depends on land powers, the dashboard should say so. If staff perform an action, the audit log should record it. If a feature is disabled by subscription or missing add-on, the dashboard should show why.

Good owner-facing wording

WatchTower can help you review alerts and request land actions, but it cannot bypass Second Life permissions. Eject, ban, and access tools only work when the in-world object has the required parcel, group, or estate powers.