Settings

The Settings page contains portal-wide configuration. Changes made here can affect every user, service limit, entity limit, scheduled check, and observation-mode component, so Settings should normally be managed by authorised administrators.

The current portal has four tabs:

Tab	Purpose
General Settings	Dashboard behaviour, default timezone and billing value, default service plugins, available timezones, and administrator notifications.
Periodic Executions	User inactivity duration, threshold-check frequency, and certificate-expiration checks.
Connectivity	Shared Redis settings for limits, the documentation URL, and the Grafana datasource ID.
Deployment Configuration	Observation Mode and the AWS region used by its components.

Open Settings from the bottom section of the portal navigation. If it is not visible, your user group may not have access to portal settings.

Warning

Each tab has its own Submit button. Switching tabs does not save the current tab. Submit and confirm the success message before moving to another tab.

Before changing settings

1. Record the current values or take a screenshot that does not expose passwords.
2. Confirm which environments and users the change will affect.
3. Obtain approved values for infrastructure fields such as Redis, Grafana, documentation hosting, and AWS region.
4. Make one related group of changes at a time.
5. Select Submit and wait for the success message.
6. Test the affected portal or gateway behaviour.
7. Restore the previous values if verification fails.

Do not copy passwords, access keys, or other secrets into tickets, screenshots, or documentation.

General Settings

The General Settings tab controls portal defaults and notifications. It is divided into General Settings, Plugins & Timezones, Email Notifications, and Notify Administrators When.

General fields

Setting	What it controls	Guidance
Dashboard Refresh Interval (ms)	How frequently the Dashboard requests refreshed data.	Enter zero or a positive whole number. 0 disables polling. Very short intervals increase browser and backend activity.
Default Timezone	The timezone used to offset usage periods when an entity or service has no timezone.	Select the organisation's agreed fallback timezone. Entity- or service-specific values take precedence where configured.
Default Billing Limit	The limit, in megabytes, passed to Grafana when no service or entity limit exists.	This is a reporting fallback, not a replacement for creating an enforced Service Limit or Entity Limit. Enter zero or a positive value.

For the dashboard refresh interval, milliseconds must be used: 10000 means 10 seconds and 60000 means one minute. A lower number updates the page more often but creates more frequent requests. If live refresh is not required, use a larger approved interval rather than an unnecessarily aggressive value.

Plugins & Timezones

This section contains two inner tabs.

Plugins

Default plugins are templates added to newly created services. They reduce repetitive configuration when every new service should begin with the same baseline plugin.

To add a default plugin:

1. Select Plugins under Plugins & Timezones.
2. Select Select & Add Default.
3. Choose the plugin.
4. Select Configure Plugin on its card.
5. Complete the plugin-specific fields and save the modal.
6. Select the page-level Submit button to save General Settings.

The plugin card's delete icon removes that plugin from the default list. It does not remove plugin instances that have already been created on existing services.

Important

Default plugins are used for future service creation. After changing a template, review whether existing services also need an equivalent manual update.

Plugin fields vary by type. Follow the Plugins guide and the service owner's approved design. Do not add a default plugin merely because it is available; every new service may inherit the operational or security effect.

Timezones

The Timezones inner tab manages the timezone values available for configuration elsewhere in the portal. Enter a valid IANA-style timezone such as Africa/Johannesburg, then press Enter to add it as a chip.

Before removing a timezone, check whether an entity or service currently uses it. Removing a value from the available list does not automatically tell an administrator which existing records depend on it.

The Default Timezone dropdown is the fallback used when no more specific value is set. Keep the default in the available timezone set to avoid confusing future administrators.

Email Notifications

Setting	What it controls	Guidance
Default Sender Name	The sender name displayed on email generated by the portal.	Use a name recipients will recognise, such as the environment or platform name.
Default Sender Email	The sender email address used by portal messages.	Enter a valid address from an approved sending domain.

These settings identify the sender; they do not configure an SMTP or other mail transport on this page. If messages are not delivered, also check the environment's mail service, domain verification, spam/quarantine handling, and application logs.

Notify Administrators When

Setting	Effect
Node is Down or Unresponsive	Sends a notification when a monitored gateway node fails its health check. Node health checks must be enabled for this to produce useful alerts.
An API is Down or Unresponsive	Sends a notification when a monitored API fails its health check. API health checks must be enabled.

Enabling a notification switch does not create health checks. Confirm that monitoring exists and that the destination mailboxes or integrated applications are actively monitored. Test the notification path after changing sender information or health-check configuration.

Periodic Executions

Periodic Executions controls time-based portal behaviour: inactive user sessions, limit-threshold checks, and certificate-expiration checks.

Session Inactivity

Session Duration (seconds) is the period of inactivity after which the user is logged out. Enter zero or a positive whole number.

Examples:

Desired duration	Value
15 minutes	900
30 minutes	1800
60 minutes	3600

Choose a duration that matches the organisation's security policy. A short duration protects unattended sessions but may interrupt administrators completing long forms. After changing it, test an ordinary user session and verify that unsaved work is handled as expected.

Threshold Interval

Threshold Check Interval is the frequency, in minutes, at which configured threshold checks run. It applies to alert processing such as daily and monthly limit thresholds.

A shorter interval can deliver warnings sooner but runs checks more often. A longer interval reduces scheduling activity but can delay notification. The value controls the check schedule; it does not alter the threshold percentage configured on an Entity Limit or Service Limit.

For example, a threshold configured at 80% is still 80% whether the interval is 5 or 30 minutes. The interval only changes how soon the scheduled process notices that usage has crossed that point.

Certificate Expiration Cron

This section checks certificates stored in the portal and notifies recipients when they are close to expiry.

Setting	Required when enabled	What it controls
Enable Certificate Expiration Checks	—	Turns the scheduled certificate check on or off.
Frequency (Minutes)	Yes	How often the certificate check runs.
Certificate Expiration (Days)	Yes	How many days before expiry a certificate should be considered due for warning.
Notification Emails	Yes	The recipients of expiration notifications.

Enter each email address and press Enter so that it appears as a chip. Invalid addresses prevent the form from being submitted.

A practical configuration might run the check every day and warn well before the certificate renewal lead time. Calculate the frequency in minutes—for example, 24 hours is 1440 minutes—and choose a warning period that gives the responsible team enough time to obtain, approve, and deploy a replacement certificate.

After enabling the job:

1. Confirm all required fields are populated.
2. Select Submit.
3. Check that the recipients can receive portal email.
4. Use a safe test certificate or controlled environment to verify the warning flow.
5. Review the Certificates page for the actual expiry dates.

Connectivity

Connectivity contains shared infrastructure values used by limits and portal links. Incorrect settings can affect multiple services at once, so obtain values from the platform team.

Service-limit Redis override

Override Service Limit Policy? forces both service and entity limits to use the Redis policy and shared Redis settings entered on this page.

Use the override when the deployment requires a centrally managed counter store. It is especially relevant to multi-node gateway environments, where local counters on separate nodes would not represent one shared total.

Setting	Required with override	What it controls
Redis Host	Yes	One or more Redis server addresses. Enter a host and press Enter to add it.
Redis Port	Yes	Redis listener port, from 0 to 65535. The form defaults to 6379.
Redis Password	Yes	Password used to authenticate to Redis. It is masked and can be temporarily revealed with the eye icon.
Redis SNI Server Name	No	Server name sent during the TLS connection when SNI is required.
Redis SSL	No	Enables an encrypted Redis connection.
Redis SSL Verify	No	Verifies the Redis server certificate when SSL is enabled.

When the override is off, the host, port, and password are not required by this form, and individual Entity Limit or Service Limit configuration can determine the counter policy. When it is on, incomplete Redis details make the form invalid.

Warning

Enabling the override with an unreachable or incorrectly secured Redis server can prevent reliable limit calculation. Review the Fault Tolerant setting on service and entity limits to understand whether traffic continues or is blocked during a counter-store failure.

Before submitting an override change, verify DNS, network access, port, authentication, TLS requirements, SNI, certificate trust, database choice in the limit configuration, and expected failover behaviour. Never expose the Redis password in screenshots.

Documentation URL

Documentation URL is required and controls the destination opened by the portal's online documentation links. Enter the complete base URL, including the scheme, such as https://help.example.com.

After changing it, use the portal's Documentation link and confirm that it opens the expected environment. Avoid localhost or private test addresses in a shared production portal because they resolve from each user's device, not necessarily from the portal server.

Grafana Datasource ID

Grafana Datasource ID identifies the datasource used by Grafana queries. Copy the exact ID supplied by the reporting/platform administrator. This is an identifier, not a Grafana dashboard URL.

After changing it, open the affected reports and confirm that they load data for the correct environment. An incorrect datasource may produce empty panels or query errors even when Grafana itself is reachable.

Deployment Configuration

Deployment Configuration controls whether the portal operates with Observation Mode components and which AWS region contains those components.

Enabled Observation Mode

Observation Mode is used when Obsidian reads usage data from external sources instead of receiving the traffic through the Obsidian Gateway in the normal request path.

Enable this only for a deployment designed and provisioned for Observation Mode. The switch does not create the required AWS resources, permissions, data sources, or ingestion jobs by itself.

AWS Regions

Select the region from which the deployment's Observation Mode components can be reached. Use the region provided by the platform or deployment owner. A mismatched region can prevent the portal or backend from reaching the expected components.

When changing deployment mode:

1. Confirm that the required components exist in the selected region.
2. Confirm network connectivity and IAM permissions.
3. Verify that usage data is being received from the external source.
4. Select Submit and confirm the success message.
5. Monitor ingestion, usage reports, and errors after the change.

See Observation Mode for the operational workflow and related data sources.

Warning

Changing deployment mode is an architectural change, not a cosmetic portal preference. Coordinate it with the platform, reporting, and operations teams.

Saving and verifying changes

The Submit button is disabled while a form contains invalid values. Required fields are indicated on the page, and numeric fields reject negative values. If Submit remains disabled:

• check the current tab for red validation messages;
• confirm required chip fields contain at least one accepted item;
• press Enter after typing a host, timezone, or email chip;
• check email address formatting;
• check the Redis port range; and
• complete conditional fields exposed by an enabled switch.

After a successful submission, refresh the page and confirm the saved values. Then test the feature affected by the change—for example, dashboard refresh, documentation link, threshold notifications, certificate emails, Grafana reports, or Observation Mode ingestion.

Troubleshooting

Settings is not visible

Your user group may not have access to the Settings feature. Ask an administrator to review your role rather than sharing an administrator account.

A saved value appears to revert

Wait for the success message before leaving the tab, then refresh the page. If the old value returns, check for a failed update notification, browser errors, or backend settings-storage errors.

Dashboard data does not refresh

Check Dashboard Refresh Interval (ms). A value of 0 disables polling. Confirm that the dashboard data source is available before reducing the interval.

Certificate notifications are not sent

Confirm the expiration switch is enabled, frequency and warning days are populated, each recipient was accepted as a chip, and the default sender/mail environment is operational. Also confirm that the certificate exists in the portal and has an expiry date within the warning window.

Limits behave differently after a Connectivity change

Check whether Override Service Limit Policy? was enabled. Validate the Redis hosts, port, authentication, SSL, certificate verification, and SNI settings. Review both Service Limits and Entity Limits because the override applies to both.

Documentation opens the wrong site

Correct Documentation URL, submit the Connectivity tab, refresh the portal, and test the Documentation navigation link again. Include the correct http:// or https:// scheme.

Observation Mode does not receive data

Confirm the switch, selected region, external source, deployed components, networking, IAM permissions, and ingestion logs. Enabling the portal setting alone is not sufficient to provision the Observation Mode solution.