Last updated: 12 August 2026. Applies to the AwayBot Slack app.
AwayBot replies on your behalf when a teammate mentions you while you are out of office. To notice a
mention it has to look at the text of messages in the conversations it is in — that is what
the channels:history, groups:history and im:history permissions are
for. That text is examined in memory, only to find <@USER> mentions, and is then
discarded: message content is never stored and never logged. What AwayBot does store is
small and listed in full below. Everything is
deleted when you uninstall the app. We do not sell or share your data, there is no advertising or
cross-site tracking, and nothing is sent to any AI model.
AwayBot keeps a small SQLite database with four tables, and nothing else:
| Table | Contents |
|---|---|
installations |
One row per workspace: your Slack team (or enterprise) ID and the Slack installation record, which contains the bot OAuth token, the bot user ID, the granted scopes and the ID of the person who installed the app. This row is encrypted at rest with AES-256-GCM before it is written. |
away |
One row per out-of-office user: the workspace ID, your Slack user ID, the optional
from- and to-dates, the optional timezone you set with tz=, whether the entry is currently
on or off, when it was created, and the out-of-office message you typed. That message is
free text you wrote, so it can contain anything you put in it — a colleague’s name, a return date, a
reason. It is stored as plain text, without application-level encryption, because
AwayBot has to post it back into Slack verbatim. The row exists only while your out-of-office does:
/awaybot off deletes it. |
billing |
Per workspace: whether it is on the paid plan, since when, and the Stripe customer ID. Stored unencrypted. No card details ever reach us — Stripe holds those. |
reply_log |
The reply throttle. One row per user and channel: the workspace ID, the out-of-office user’s Slack user ID, the channel ID, and the timestamp of the last reply AwayBot posted there. It exists so AwayBot does not repeat itself in the same conversation within 30 minutes. Be aware of what it implies: for an out-of-office user, it records which channels they were mentioned in and roughly when. It holds no message text and no channel names. Stored unencrypted, and kept only briefly — see “Data retention and deletion” below. |
<@USER> mentions, and discarded. No code path writes a message body, and the app has no
table it could write one to.| Scope | Used for |
|---|---|
commands | receive the /awaybot slash command |
chat:write | post the out-of-office reply in the thread |
app_mentions:read | answer with a short help message when the bot itself is mentioned |
channels:history | receive messages in public channels the bot is in, so it can see that someone was mentioned |
groups:history | the same for private channels the bot has been added to |
im:history | the same for direct messages with the bot |
users:read | requested at install, but not used. No code path in
AwayBot calls a Slack users.* method, so no profile is ever fetched. The scope is a leftover
in the app’s configuration; we cannot remove it from an installation that already granted it, but nothing
reads it. |
The three *:history scopes only deliver messages from conversations the bot is a member
of. Removing AwayBot from a channel stops the flow of messages from that channel immediately.
On a server we operate ourselves in the European Union, in a SQLite database file that is not reachable from the internet. Only AwayBot reads it. The installation record — the row holding your Slack OAuth token — is additionally encrypted with AES-256-GCM before it is written, so the database file on its own does not yield a usable token. The other three tables are stored as ordinary database values; the table above says exactly what is in them.
AwayBot writes operational log lines for debugging. They contain workspace IDs, the fact that a reply failed and Slack’s error code for it, and the type of a Stripe billing event. Message text is never logged, and neither is your out-of-office message. Logs are rotated by size rather than kept for a fixed period, so older lines are discarded as new output arrives.
When the app is uninstalled from your Slack workspace, Slack sends an
app_uninstalled event and AwayBot deletes all four tables’ rows for that
workspace in a single transaction: the installation, every out-of-office entry, the billing row and the
whole reply log. Nothing about that workspace remains.
/awaybot off deletes your entry — the whole row, including the message you
wrote, the from- and to-dates and the timezone. Nothing about that out-of-office is kept, and the command
confirms what it removed. Setting a new out-of-office afterwards starts from scratch; no date or timezone
carries over from the deleted one.
/awaybot off only flagged the
entry inactive and left your message, dates and timezone in the database. That is no longer the case: the
command deletes. Entries left inactive by the old behaviour were removed when this change was deployed.
Rows in reply_log are deleted by a daily job once they are
more than a day old. Only the most recent timestamp per user and channel has any function —
it is what stops AwayBot repeating itself within 30 minutes — so older rows are removed rather than kept.
The job never deletes a row that the 30-minute throttle is still using.
Entries in away have no expiry date: an out-of-office you set stays until you switch it off
with /awaybot off, replace it, or uninstall the app. An entry whose end date has passed is
inactive and AwayBot stops replying, but the row is yours to keep or clear.
We do not sell, rent or share your data with third parties for their own purposes. Data is exchanged only with the providers needed to run the app:
If you are located in the European Economic Area, you have the right to access, rectify or erase the personal data held about you, to restrict or object to its processing, and to data portability. You can exercise these rights by contacting us at the address below, or by uninstalling the app — which deletes your workspace’s data as described above.
Communication with Slack and Stripe uses HTTPS. Every inbound Slack request is verified against Slack’s request signature before it is acted on, and every Stripe webhook is verified against Stripe’s signature over the raw request body — an unsigned or forged webhook is rejected. The Slack OAuth token is encrypted with AES-256-GCM at rest.
If this policy changes, the updated version is published on this page with a new “last updated” date.
Questions about this policy: info@kyc-checks.nl.