Administrator guide
Health, alerts and logs
The Admin Workspace dashboards, engine health and alerts, the audit history, and how to collect logs for support.
The Admin Workspace
Open Warde > Admin Workspace, or /x/66256/warde-admin/home. It needs the Warde administrator role. The left rail has four items: Home (the dashboards), List (every list, by category), Access health, and Setup (the three wizards).
Dashboards
| Dashboard | What it shows |
|---|---|
| Warde Admin Overview | Failed and parked operations, leaver removals not finished, manual work waiting more than 7 days, engines needing attention, and sync discrepancies in the last 7 days |
| Fulfilment operations | The queue, throughput, service level against promised dates, and trends |
| Leavers | Leaver removals not finished, failed, past their promised date or cancelled, and access still active after someone left |
| Access & entitlements | The catalog, and who holds what |
| Access reviews | Running campaigns, reviews past due, undecided lines, removals not yet confirmed |
| Integration & data quality | Engine status and sync, and gaps in the data |
| Access health | Approval policy, collection, entitlement, bundle and access review health |
Every tile opens the list behind it.
Lists to check each day
| List | Why |
|---|---|
| Operations > Failed or parked | Work that needs a person |
| Engines > Needs attention | Engines degraded, failing health checks or not synced |
| Audit > Sync discrepancies | Syncs that refused to retire records because too many disappeared at once |
| Accounts & access > Orphan accounts | Accounts that match no user |
| Data quality > Requestable but not fulfillable | Access people can ask for that nothing can deliver |
| Data quality > Entitlements with no owner | Access with nobody to approve its inclusion in bundles or review it |
Engine health
The Warde engine health check job checks every enabled engine each hour with a real, authenticated call, and records the result on the engine. Run health check on an engine, or Test connection in Guided Setup, runs it on demand.
| Engine status | Meaning |
|---|---|
| Active | Working normally |
| Read only | Syncs, but changes go to tasks. An Entra engine consented for reads only returns to this status when it recovers. |
| Degraded | An outage was detected. Its work is held and sent again when it recovers. |
| Disabled | Switched off: no sync, no health check and no changes |
Warde marks an engine degraded when any of these trips:
| Setting | Default | Trips when |
|---|---|---|
alerting.hour_threshold | 10 | That many calls fail in an hour |
alerting.day_threshold | 0 (off) | That many calls fail in a day |
alerting.auth_threshold | 3 | The engine refuses the credentials that many times in an hour |
alerting.probe_threshold | 2 | That many health checks in a row fail |
A failed health check is checked again within 5 minutes. The engine returns to active when the latest health check passes and nothing has failed for alerting.hold_down_mins (15). Work parked while it was degraded is put back on the queue.
To end an alert by hand, enable the engine again in Guided Setup. If it is still broken, the next check marks it degraded again.
Engine alerts
Warde can tell someone when an engine is degraded. Set the default in x_66256_warde.alerting.sink, or per engine in Guided Setup step 2 or on the engine form.
| Sink | What happens |
|---|---|
none (the default) | Nothing is raised. The engine's status and the dashboards still show it. |
incident | An incident is opened, Warde: engine <name> is failing calls. Recovery adds a work note. If the incident is closed while the engine is still down, a new one is raised after 24 hours (alerting.reraise_after_mins). |
em_event | An event is sent to Event Management, and a clear event when it recovers. Needs the ITOM subscription. |
both | Both of the above |
Incident fields come from alerting.incident_group, alerting.incident_caller, alerting.incident_impact and alerting.incident_urgency. Send test alert on an engine sends a test through its sink.
The audit history
Every request, approval, grant, removal, review decision, setting change and onboarding step is written to Warde's audit history, Audit > All audit events. It is append-only: nobody can edit or delete an entry through the interface, including administrators. It is kept for seven years by default; set the retention in Guided Setup step 11.
Other audit lists:
| List | What is in it |
|---|---|
| Sync discrepancies | Records a sync would have retired, held back for you to check |
| Manual overrides | Changes recorded by hand, such as Complete manually |
| Terms accepted | Every set of terms a requester accepted, and for whom |
Logs
Warde writes to the platform's application log, Warde > Application logs or System Logs > Application Logs, with source x_66256_warde.
The level is x_66256_warde.logging.verbosity, set in Guided Setup step 13:
| Level | Writes | Use it for |
|---|---|---|
| Error | Failures only | An instance that wants its log to hold failures only |
| Warn (the default) | Failures and warnings | Everyday use |
| Info | Also the story of each request, operation, sync run and campaign | Reproducing a problem, or leaving on for a day |
| Debug | Also the detail behind every decision | A short reproduction, then back to Warn |
A healthy instance writes almost nothing at Warn.
Every line starts with a bracketed area, so one search answers one question:
| Prefix | Covers |
|---|---|
[Warde request] | Request lines, their checks, and settling a request |
[Warde approvals] | Approval chains, rules and requests that stopped |
[Warde SoD] | Separation of duties checks |
[Warde dispatch], [Warde queue] | Fulfilment operations, retries and triage |
[Warde sync] | Imports from engines |
[Warde health], [Warde alerting] | Health checks and engine alerts |
[Warde removal], [Warde expiry] | Removals and expiring access |
[Warde bundle] | Access bundles |
[Warde review], [Warde UAR] | Review decisions and campaigns |
[Warde lifecycle], [Warde REST] | The joiner, mover and leaver API |
[Warde setup], [Warde onboard] | Guided Setup and Collection Onboarding |
[Warde notification] | Emails and their links |
Collect logs for a support request
- In Guided Setup step 13, set the log level to Info, or Debug if the problem is quick to reproduce.
- Reproduce the problem. Note the time and the request or record number.
- Open Warde > Application logs, filter to source
x_66256_wardeand the time window, and export the list. - Set the level back to Warn.
- Export the audit events and the fulfilment operation for the record concerned.
Send them to support@warde.app, as Warde > Contact Support describes.
Support
Warde > Contact Support gives the support address, hours (09:00 to 17:00 Melbourne time, Monday to Friday, except Victorian public holidays), and how quickly each severity is answered:
| Severity | First response |
|---|---|
| 1 | 4 business hours |
| 2 | 1 business day |
| 3 | 3 business days |
| 4 | 5 business days |
Warde is supported by its publisher, not by ServiceNow. If access has to change before support answers, make the change in the identity system itself.