Dev UI panel

Master toggle — Activate/deactivate all chaos with a single click. When inactive, the status dot turns red and the Deactivate button becomes Activate, and the status bar says why chaos is off (a deactivation from this dev session, a fired auto-off, quarkus.goblin.enabled=false, or a test run without quarkus.goblin.test.enabled). A deactivation belongs to the dev session: it survives the live reloads of the running dev process, so saving a file does not re-arm chaos, and it is kept for the same reason as the auto-off, outside .goblin-state.json. A new process takes the active flag back from quarkus.goblin.enabled.

Active goblin — While chaos is active, an animated goblin casting a spell sits in the bottom-right corner of the Chaos Dashboard and History pages, so a glance tells you the application is under attack; it disappears as soon as chaos is off. With the operating system’s reduced-motion setting, a still image replaces the animation.

Kill switch — Disable all (or Ctrl/Cmd + Shift + X while the Chaos Dashboard is open) asks for confirmation, then deactivates chaos, turns every assault type and client-side assault off, resets the profile to NONE and cancels any pending auto-off.

Auto-off — Optionally deactivate chaos automatically after 5, 10, 30 or 60 minutes. The deadline is held by the engine, not by the browser: chaos switches off at the deadline even when the Dev UI is closed, and a pending auto-off survives a live reload. Once it has switched chaos off, chaos stays off across live reloads until you switch it on again. A countdown shows the remaining time and can be cancelled; deactivating chaos (master toggle or kill switch) cancels it too. The master toggle sends the state you asked for, so clicking Deactivate just as the auto-off fires never switches chaos back on.

Blast radius warning — A banner warns when chaos is active with two or more server-side assaults at a 100% level: every eligible request is then assaulted.

Live counters — The status bar shows the total number of assaults since the last reset (with a reset action) and one chip per source that fired (REST, service, database, messaging, REST client, WebClient), refreshed every 2 seconds together with the config.

Profile selector — Pick a predefined composite assault mode (NONE, SLOW_FAILURE, INTERMITTENT, TIMEOUT); a predefined profile other than NONE asks for confirmation before it is applied. It turns every server-side assault off, then enables its own assaults with their defaults (see Profiles). The active profile is shown in the status bar, with an override marker when a server-side toggle no longer matches the profile. Individual toggles stay overridable on top of the profile.

Custom profiles — Save current as profile asks for a name and stores the current configuration in the browser (not on the server). A custom profile is re-applied from the profile selector (Custom: <name>) and removed with Delete active. The status bar keeps showing the predefined profile held by the engine (often None (manual)); the custom name only appears in the selector.

Scenarios — Save current as scenario stores the whole assault configuration under a name, on disk; Load replaces the configuration by the selected scenario and Delete removes it. See Scenarios.

Assault type toggles — Independent on/off switches for each assault type (Latency, Exception, HTTP Status, Dependency Degradation, Response Body, Response Header). Multiple types can be active simultaneously. Enabled types are highlighted with the Quarkus primary color, and each row shows its priority.

Priority badges — Each assault row shows when it runs: 10 latency, 20 exception, 30 HTTP status and 40 dependency degradation run in that order before the endpoint (the first aborting one short-circuits the request); R marks the response-phase transformations (response body, then response headers); C marks the client-side assaults on outgoing calls.

Client-side assault toggles — A dedicated section controls client latency and client exception, applied to outgoing MicroProfile REST Client and Vert.x WebClient calls. They default to off and reuse the latency range and exception class/message configured above.

Quick picks — One-click presets in the Exception section (verified exception classes, served by the engine and guaranteed to be throwable — no fallback) and in the HTTP Status section (500, 503, 429, 404). A pick fills the form; click Save to apply it.

Config sections — Each assault type has its own configuration section (latency range, exception class/message, HTTP status code/message, response body mode/percentage, response header rules as editable rows with a single Save headers action). While a type is off, its section only shows a summary of the current values (e.g. Current: 503. Enable HTTP status assault to configure.); enable the type to display and edit its parameters. Every section has its own Save button, enabled once the form is modified.

Validation — The latency, exception, HTTP status, response body and level forms are checked as you type: an invalid value (for example a latency min greater than max) shows a message and keeps Save disabled. The response header rules are checked when you click Save headers: an empty name or a name that is not an HTTP token is reported in an error toast and nothing is saved. Values the forms accept are still checked by the engine, which may correct them (see Configuration validation); the correction is shown in a toast.

Target level — A numeric field (0-100%) in the status bar sets the percentage of affected requests, saved with its own button.

Chaos layers — A dedicated section lists one switch per chaos layer, from the deepest to the shallowest: Database, Messaging, Service, Outbound HTTP and Inbound REST (DATABASE, MESSAGING, SERVICE, HTTP_OUT, HTTP_IN). Only the armed layers are candidates each request; the deepest armed layer whose probability roll passes wins for that request (see Chaos layers). Database (requires a JDBC datasource) and Messaging (requires quarkus-messaging) are marked unavailable and cannot be switched on when the application lacks the matching extension. By default HTTP_IN and HTTP_OUT are armed, which keeps the pre-layers behaviour; switching every layer off re-arms that default.

Danger zone — Export the current configuration as a JSON file, import a previously exported one (or any partial config), or reset the whole configuration. The reset asks for confirmation, then restores the built-in defaults — not the values of application.properties: latency assault on with 100-5000 ms, every other assault off, HTTP 503, level 100, no header rules, layers HTTP_IN + HTTP_OUT. It leaves the active flag and any pending auto-off unchanged. An import is applied at once: a rejected file changes nothing.

All changes apply instantly — no restart needed. A WARN log is emitted in the console for every change, and a toast confirms each action in the UI. If the engine corrects a value (see Configuration validation), the toast shows the applied correction.

Persistence — In dev mode every configuration change is written to .goblin-state.json in the project directory, and that file is loaded at the next start instead of the quarkus.goblin.assault.* and quarkus.goblin.target.level properties (the active flag excepted). The deactivation and the auto-off are deliberately kept out of that file, so it can never arm an extension you disabled with quarkus.goblin.enabled=false. Delete the file to start again from application.properties (see Configuration reference).

Save — Save current as scenario asks for a name (1 to 64 letters, digits, spaces, - or _) and writes .goblin/scenarios/<name>.json in the project directory, in the .goblin-state.json format. Saving under an existing name asks before replacing it.

Load — replaces the whole configuration by the selected scenario, as a single change. A scenario never holds the active flag: loading one leaves chaos on or off as it is. An invalid value in a hand-edited file falls back to a valid one with a log, as for any other configuration change.

Delete — removes the scenario file; the current configuration is not touched.

the timestamp of the assault — millisecond precision, with the full ISO timestamp shown on hover

the assaulted target: the resource method (SampleResource.hello), the application bean method (SERVICE), Database <datasource> connection, Messaging <consumer>, or the outgoing call (REST-Client GET <url>, WebClient GET <url>)

the assault type shown as a colored badge — Latency, Exception, HTTP Status, Dependency, and for response body assaults two distinct badges depending on the mode: Truncate (response-body-truncate) and Inflate (response-body-inflate). Response header rules are shown as Header Set: <name> / Header Remove: <name>

the actual applied latency duration when the assault was a latency injection

the active assault configuration at the time of the assault, stored compactly in an Active Config cell — click the cell to expand or collapse it

the current status (active/inactive) and target level

the current assault configuration (active profile, armed chaos layers, latency, exception, HTTP status, dependency degradation, response body toggles and values, response header rules, client-side assault toggles)

the full assault history, including the source of each assault (server, service, database, messaging, rest-client, webclient), the actual latency duration applied for each latency assault and a snapshot of the active configuration at the time of each assault — so a config change between two calls is clearly visible (e.g. latency enabled (100 - 500 ms) vs latency enabled (1000 - 5000 ms))