1---
2stage: Growth
3group: Activation
4info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
5type: reference, howto
6---
7
8# Broadcast messages **(FREE SELF)**
9
10GitLab can display broadcast messages to all users of a GitLab instance. There are two types of broadcast messages:
11
12- Banners
13- Notifications
14
15Broadcast messages can be managed using the [broadcast messages API](../../api/broadcast_messages.md).
16
17## Banners
18
19Banners are shown on the top of a page and in Git remote responses.
20
21![Broadcast Message Banner](img/broadcast_messages_banner_v12_10.png)
22
23```shell
24$ git push
25...
26remote:
27remote: **Welcome** to GitLab :wave:
28remote:
29...
30```
31
32If more than one banner is active at one time, they are displayed in a stack in order of creation.
33
34## Notifications
35
36Notifications are shown on the bottom right of a page and can contain placeholders. A placeholder is replaced with an attribute of the active user. Placeholders must be surrounded by curly braces, for example `{{name}}`.
37The available placeholders are:
38
39- `{{email}}`
40- `{{name}}`
41- `{{user_id}}`
42- `{{username}}`
43- `{{instance_id}}`
44
45If the user is not signed in, user related values are empty.
46
47![Broadcast Message Notification](img/broadcast_messages_notification_v12_10.png)
48
49If more than one notification is active at one time, only the newest is shown.
50
51## Add a broadcast message
52
53To display messages to users on your GitLab instance, add a broadcast message.
54
55To add a broadcast message:
56
571. On the top bar, select **Menu > Admin**.
581. On the left sidebar, select **Messages**.
591. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags.
60   The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties:
61    - `color`
62    - `border`
63    - `background`
64    - `padding`
65    - `margin`
66    - `text-decoration`
671. Select one of the suggested background colors, or add the hex code of a different color. The default color is orange.
681. Select the **Dismissable** checkbox to enable users to dismiss the broadcast message.
691. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `mygroup/myproject*`.
701. Select a date for the message to start and end.
711. Select **Add broadcast message**.
72
73NOTE:
74The **Background color** field expects the value to be a hexadecimal code because
75the form uses the [color_field](https://api.rubyonrails.org/v6.0.3.4/classes/ActionView/Helpers/FormHelper.html#method-i-color_field)
76helper method, which generates the proper HTML to render.
77
78When a broadcast message expires, it no longer displays in the user interface but is still listed in the
79list of broadcast messages.
80
81## Edit a broadcast message
82
83If you need to make changes to a broadcast message, you can edit it.
84
85To edit a broadcast message:
86
871. On the top bar, select **Menu > Admin**.
881. On the left sidebar, select **Messages**.
891. From the list of broadcast messages, select the edit button for the message.
901. After making the required changes, select **Update broadcast message**.
91
92Expired messages can be made active again by changing their end date.
93
94## Delete a broadcast message
95
96If you no longer require a broadcast message, you can delete it.
97You can delete a broadcast message while it's active.
98
99To delete a broadcast message:
100
1011. On the top bar, select **Menu > Admin**.
1021. On the left sidebar, select **Messages**.
1031. From the list of broadcast messages, select the delete button for the message.
104
105When a broadcast message is deleted, it's removed from the list of broadcast messages.
106
107<!-- ## Troubleshooting
108
109Include any troubleshooting steps that you can foresee. If you know beforehand what issues
110one might have when setting this up, or when something is changed, or on upgrading, it's
111important to describe those, too. Think of things that may go wrong and include them here.
112This is important to minimize requests for support, and to avoid doc comments with
113questions that you know someone might ask.
114
115Each scenario can be a third-level heading, e.g. `### Getting error message X`.
116If you have none to add when creating a doc, leave this section in place
117but commented out to help encourage others to add to it in the future. -->
118