Niklas Ye
1140d773f8
Release / build (amd64, darwin) (push) Failing after 9s
Release / build (arm64, darwin) (push) Failing after 10s
Release / build (amd64, linux) (push) Failing after 10s
Release / release (push) Has been skipped
Release / build (arm64, linux) (push) Failing after 11s
terdut-server v0.4.0 splits the alerts row into two objects, and the
endpoints this client drove for acknowledgement, comments and archiving
are gone. Pointing the same screens at the new paths would have missed
the point of the split: alerts are now Alertmanager's record, read-only
and carrying no human state, while the incident is the thing anyone
actually works on.
Incidents lead the section list and are what the client opens on. The
queue shows severity, status, assignee and age, and the detail view adds
what only exists server-side now: the group labels Alertmanager
correlated on, the member alerts, and an append-only timeline where
system events and notes are interleaved. That timeline is the whole
history the server keeps — alert rows are still mutated in place — so
rendering it in order matters more than styling it.
Actions all move onto the incident: a/A acknowledge, s assign, z/Z
snooze, c note, d delete note, x archive, R resolve.
Two of those need care rather than a keybinding:
- R, not r, resolves, and it asks first. The server treats a manual
resolve as terminal: a later occurrence opens a new incident instead
of reopening this one, and an alert that never stops firing leaves
the incident closed for good. A stray keypress is not recoverable,
so the prompt says what it means.
- x refuses on an open incident rather than archiving it, since
archiving unresolved work only hides it. Snooze is offered as the
"not now" answer, and the client treats a snoozed_until in the past
as not snoozed, matching the server, which sweeps nothing.
Statistics lead with MTTA and MTTR, neither of which was computable
before. The server sends null until something has actually been
acknowledged or resolved, and that renders as — rather than 0: no data
is a different claim from instant.
Alerts keep a tab of their own as the raw feed — useful for asking what
Alertmanager is really sending — with an Incident column replacing Ack
By, and i in the detail view jumping to the incident where something can
be done about it. Archived now holds archived incidents; archiving an
alert is server-side housekeeping and no longer a user action.
BREAKING CHANGE: requires terdut-server v0.4.0 or later. Against an
older server every incident request 404s. Use terdut-tui v0.3.x with
servers before v0.4.0.
terdut-tui
A terminal user interface for terdut-server. Communicates with the server over its REST API.
Written in Go using Bubbletea.
Features
- Incident queue — open incidents with severity, status, assignee and age, auto-refreshing
- Incident actions — acknowledge, assign, snooze, note, resolve and archive
- Timeline — the full history of an incident, system events and notes together
- Alert feed — the raw read-only alerts underneath, each linked to its incident
- On-call schedule — visual calendar of who is on duty, assign and remove entries
- Statistics — MTTA and MTTR, plus alert frequency by name, hour and day
- User management — add and remove users, manage API keys
Requires terdut-server v0.4.0 or later. Earlier servers have no incidents API; use terdut-tui v0.3.x with those.
Alerts and incidents
The server keeps two objects and this client follows that split:
- An alert is Alertmanager's record — firing or resolved, and read-only here.
- An incident is the work item. It is what you acknowledge, assign, snooze, discuss and resolve, and it is where all the actions live.
Incidents are correlated by the groupKey Alertmanager already computed from your
group_by configuration, so several alerts commonly share one incident.
Two behaviours worth knowing before you press a key:
- Resolving is final. The server treats a manual resolve as terminal: a later occurrence opens a new incident rather than reopening this one, and if the alert underneath never stops firing the incident stays closed. The TUI asks for confirmation before doing it.
- Snooze is the "not now" button. It hides an incident from the default queue without closing it, and expires on its own.
Installation
Download the latest release binary for your platform from the releases page, or build from source:
go install github.com/yeniklas/terdut-tui@latest
Configuration
Create ~/.config/terdut-tui/config.yaml:
server_url: https://terdut.example.com
api_key: <your-api-key>
refresh_interval: 30 # seconds, optional
The API key is generated in terdut-server. See the server documentation for how to bootstrap a user and issue an API key.
Usage
terdut-tui start the TUI
terdut-tui --version print version
terdut-tui --self-update update to the latest release
Keybindings
Global:
| Key | Action |
|---|---|
j / ↓ |
Move down |
k / ↑ |
Move up |
tab / shift+tab |
Next / previous section |
enter |
Open detail |
esc |
Go back |
r |
Refresh |
f |
Cycle filter |
S |
Statistics |
q |
Quit |
Incidents section:
| Key | Action |
|---|---|
f |
Cycle: open → triggered → acknowledged → resolved → snoozed |
x |
Archive (resolved incidents only) |
Incident detail:
| Key | Action |
|---|---|
a / A |
Acknowledge / clear acknowledgement |
R |
Resolve — asks to confirm, and is final |
s |
Assign to a user |
z / Z |
Snooze for a duration / un-snooze |
c |
Add a note |
[ / ] |
Select a note |
d |
Delete the selected note (your own only) |
x |
Archive / un-archive |
Alerts section (read-only):
| Key | Action |
|---|---|
f |
Cycle: firing → resolved → all → archived |
i |
In detail: jump to the alert's incident |
Schedule section:
| Key | Action |
|---|---|
+ / W |
Assign a day / a whole week |
d |
Remove the assignment |
← / → |
Shift the week window |
Users section:
| Key | Action |
|---|---|
n |
Create a user |
d |
Delete a user |
k |
API keys for the selected user |