APE Watchtower is the alarm system for your APEX applications: you set up sensors that monitor your applications, database, external services, or even business processes, and if one of them detects something fishy, Watchtower raises the alarm: on your Watchtower Dashboard, in your APE Inbox, or by email.

Open a Watchtower sensor from an older APE release, though, and the report reads like a database export: column headers like AT03, AT07, or VAL. They make perfect sense to whoever wrote the sensor's SQL query. Unfortunately, not to anyone else. 

APEX Project Eye 26.2 lets you replace these raw sensor attribute identifiers (eg. KEY, VAL, and AT01–AT10) with custom, human-readable labels, so Watchtower reports read like your data instead of a column dump.

A quick refresher: what KEY, VAL, and AT0x actually do

(Already comfortable with how APE sensors work? Skip ahead to Defining labels per sensor.)

Every APE sensor is defined by a SQL query. That query must return a Key column — a unique identifier for each row — and a Value column — the number being monitored. It can optionally return up to ten more columns, attribute_01 through attribute_10, that carry extra context along for the ride: an application name, an error message, a component type, anything that helps explain why a reading looks the way it does. Watchtower shows these as KEY, VAL, and AT01–AT10 everywhere: in reports, summaries, and escalation messages.

Take a basic example: monitoring the number of errors raised by each of your applications in the last 24 hours.

The statement returns one row per application that had activity in the last 24 hours, with its error count. Here, the application ID is the key, the error count is the recorded value, and the application name is attribute_01:

Those column names are SQL aliases, never designed for anyone to actually read. That's fine while you're writing the query. It stops being fine the moment someone else — a teammate, a new hire, or an AI agent — has to make sense of the result without the context that was in your head when you wrote it.

This isn't new, either: Watchtower's escalation messages have always supported # placeholders (#KEY#, #VALUE#, #ATTRIBUTE_01#, and so on) so you can pull sensor data into the message text. Attribute labels extend that same idea to the names, not just the values.

Defining labels per sensor

Every sensor configuration screen now has an Attribute Labels region, where you can set a custom label for each of the sensor's attributes:  KEY, VAL, and AT01 through AT10. A label is defined per sensor, so the same attribute slot (say, AT01) can mean something different on each sensor that uses it.

Here's how to set one up:

        1. From the Watchtower Dashboard, click Sensors to open the Sensor repository.

        2. Find the sensor you want to configure and open it for editing.

        3. Select the Attribute labels tab, then type a label into any attribute you want to rename. Labels are optional — you only need to fill in the ones your sensor actually uses.

       4. Click Apply Changes.

APE ships with a set of UC predefined sensors, and we've already applied descriptive labels to all of them. Feel free to relabel them if our wording doesn't match how your team talks about the data.

A few practical limits worth knowing: Labels export with the sensor when you export it to JSON, and they come back when you import that file in another workspace. However, re-importing a sensor definition overwrites any labels already saved for it, so double-check before you re-import a sensor whose labels you've since customized locally.

You can also use labels in escalation messages: once saved, your labels also become placeholders you can drop into a sensor's escalation message text. #KEY_NAME# for your Key label, #VAL_NAME# for your Value label, and #ATTR_NAME_01# – #ATTR_NAME_10# for your custom attribute labels. Combine a label placeholder with its value placeholder for full context, e.g. #ATTR_NAME_01#: #ATTRIBUTE_01#. The original #KEY#, #VALUE#, #ATTRIBUTE_01#–#ATTRIBUTE_10#, #SENSOR_NAME#, #SEVERITY#, and #MESSAGE# placeholders still work exactly as before.

Before you save any labels, the same report shows nothing but the generic column names straight from the query:

Once you apply labels, that same report reads like this instead:

Here's a second sensor looking for errors that occurred the first time in the last 14 days, UC06 - New kind of error, with several labels already applied: Key, an attribute for the error message, and attributes for the application ID, component type, and component name:

Labels show up everywhere the raw identifiers used to

Once defined, custom labels replace the raw technical identifiers throughout the Watchtower UI, continuing with sensor UC06 from above:

• Preview Dialog: Interactive Report column headers show the custom label instead of the raw attribute name, wherever one is defined for the sensor.

• Test Escalation Channels Dialog: item labels are replaced with the custom labels too.

• Scan History: the nested Key/Value report displays custom labels in place of raw attribute names.

• Scan Details: custom headers are shown directly in the Scan Details region.

Watchtower Summary: the dashboard summary and summary email both use custom labels in place of raw attribute names when describing sensor readings.

• Sensor Escalation Channel Messages: If you've configured escalation channels per sensor to control when and how abnormal readings are communicated, the message raised when a sensor triggers uses the same custom labels in place of raw attribute names, delivered to your APE Inbox, your mailbox, or both.

Sensors without a custom label for a given attribute keep showing the raw identifier. There's no need to label every attribute on every sensor to benefit. Just label the ones where a plain-language name actually makes the data easier to read.

Especially useful for AI-generated summaries

Raw identifiers like AT03 carry no meaning on their own, not to you, and not to an AI reading them either. If you're using the AI-generated Watchtower Summary, custom attribute labels give the model the same context they give you: a reading tagged Component Name or Error Text lets it describe what actually happened, instead of producing a vague summary built around anonymous attribute slots. The Watchtower Summary examples above already show how readable that narrative gets.

Try it on your busiest sensors first

You don't need to relabel every sensor at once. Start with the ones you check most often, or the ones that keep producing reports you have to squint at to decode. Your very next Watchtower scan, summary, or escalation message on that sensor will already read better: no more matching AT03 against the SQL query to remember what it means.

Once your key sensors are labeled, you get the payoff Watchtower was built for in the first place: you stop scrolling through logs and charts hunting for what went wrong, because Watchtower brings it to your attention and now, the message actually tells you what to act on.

Already running APE 26.2? Open any sensor's Attribute Labels tab and start with the sensor you check most often. New to APE, or want to see what else Watchtower can do for you? Take a look at APEX Project Eye.