This article will describe and define the fields and forms used in your Status Page. These components appear in all versions of a Status Page, whether it's an Internal Status Page, a Public Status Page, or a Public SLA page. Together, these options provide control over the data that appears on a Status Page as well as its visual representation to visitors. You can specify the components your Page will display, the look and feel of your Page, and how your visitors will interact with the page via the Status Page configuration.
To skip to a specific section of the "Uptime.com Status Page Solution: Basic Setup" video, click the links with the !
- Status Page Settings
- Subscribing to Your Status Page
- External Access
- A Note on Markdown
These settings are common to all Status Page types.
Adjust settings that affect the visibility of your Page.
Page Name: The name of your Page.
Page Description: This text is displayed at the top of the Page for your visitors. It is possible to use markdown in this field.
Allow Users to Subscribe to this Page: Allow anyone to subscribe to receive incident & scheduled maintenance update notifications. Visitors will be able to follow an RSS feed, subscribe for SMS notifications, email notifications, receive Slack Notifications or a webhook from your status page. Note: Internal Status Pages are by default restricted to users registered to your Uptime.com account.
Make this Page Available Publicly: Make this Page publicly accessible. Uncheck this box to grant access to Uptime.com users only.
Visibility Level: Select Status Page visibility level, between Default (default public access), Uptime Users (only Uptime.com account users from within the UI), External Users (users with configured Single Sign-On applications or invited External Users logins), and Public (anyone with the Status Page URL). For most public Status Pages, a visibility level of Public is appropriate, as this will "publish" the Status Page and allow anyone with the URL to access it.
Timezone: The timezone of the Status Page. This can be changed from the drop box shown. Note, this is not the same Timezone setting from the Account Details.
Please note: "External User" setting is only available to accounts with SSO enabled.
For more information, please see our support article Securing Your Uptime.com Status Page.
URL Slug: This is the URL path/folder name that you can customize (letters, numbers, and hyphens only).
CNAME: OPTIONAL: Enter a custom subdomain to host your status page (for example: status.mysite.com). Create a CNAME DNS record for your subdomain pointing to cname.uptime.com, and it will display this Status Page.
Public URL: The publicly accessible URL slug.
Username/Password: OPTIONAL: Secure this Status Page using HTTP Basic Auth with this username/password combination.
Allow Search Engine Indexing Turn this option off to add a HTML header requesting search engines to not index your Page.
Allow drill down into individual checks: Allow visitors to view performance graphs and reports of check-based components.
If the Current Status tab is enabled: visitors will be able to view the status of components, including response time graphs, active incidents, upcoming scheduled maintenance and system metrics.
Display active incidents and scheduled maintenance: Displays active incidents at the top of the Current Status tab of your Page, and scheduled maintenance windows at the bottom of your Page.
Display components' "Response Time" graph in the "Current Status" table: Displays both response time and current status tables in the Current Status tab of your Status Page.
If the History & Incidents tab is enabled: visitors can view past incidents, including scheduled maintenance windows and historic metrics.
The History and Incidents Tab
The History and Incidents tab includes a table that tallies all changes in status, as well as response time, for given components for a given period. When incidents are manually created, the status assigned to a component is visible in the Component History table.
In the above image, the outages listed represent manually created incidents. It is important to note that incidents and component status can act separate from one another. For example, if a component status is set to change to Major Outage, and an incident is NOT manually created, the component status will return to Operational and no outage will be listed in the History and Incidents tab for your status page.
At least one incident must be created for a change in component status to be recorded in the History and Incidents tab.
Display "History & Incidents" tab on your page: Anyone can view historic graphs, metrics, component history, and past incidents.
Default date range (days): The default number of days a visitor should see. The visitor will be able to adjust the date range if the History & Incidents tab is enabled.
Uptime calculated by: Select the value that calculates global uptime; the duration of your manually-created incidents or the calculated uptime percent of your check-based components.
The Uptime % is calculated based on downtime of the Status Page’s checks (checks attached to the status page components).
This is calculated as a ratio of total uptime to total downtime of all the checks associated with the Status Page. If the checks in question were not active at any time during the report’s time span, it will calculate the “total running time” of each check displayed and remove the outages from the 100% uptime that is the starting point.
The Uptime % for the specific components is the calculated ratio of the total uptime divided by the total time of the current time period.
Please note: The calculations above are the same for the SLA report.
Enable PDF report download: Enable a PDF download of the History and Incidents report for the date range specified. This option is ON by default for Public SLA and Internal Status Pages, and OFF by default for Public Status Pages.
History Graph: Enable an interactive visualization of your components’ availability history.
Summary Metrics: Allow Page visitors to see Global Uptime, Outages, and Total Downtime
Component History: Display a table of components’ historical metrics for the selected period.
Past Incidents: Display past incidents for the selected period
You can use these settings to adjust the look and feel of your Page, and email notifications to subscribers.
Upload Logo: Upload a logo that will appear in the header of your Page. It is possible to make your logo clickable, with a link leading to a designated URL. See Company Website URL for additional details. Please note: This is not counted as a part of the “customisation option” of the status page & is available depending on the plan you are on.
Upload Favicon: A favicon that will act as the icon of your Page in the browser tab. Favicons must not exceed 192x192 px. Please note: This is not counted as a part of the “customisation option” of the status page & is available depending on the plan you are on.
Google Analytics Property ID: Your google analytics property/Measurement ID, such as UA-12345678-1 or G-1234567890.
Contact Email Address: Allow Page visitors to report issues to this email address (e.g. email@example.com).
Company Website URL: Clicking the logo of your status page will forward users to this URL.
Custom CSS: OPTIONAL: Inline CSS used to style customized HTML in the Header and Footer sections and/or to style the Page itself.
Custom Header HTML: OPTIONAL: Inline HTML to render in the header section in place of the standard logo & title.
Custom Footer HTML: OPTIONAL: Inline HTML to render in the footer section in place of the standard logo and title.
Please Note: The CSS and HTML feature is dependent on the plan you are on.
Upload Email Logo: Upload an image to use as the logo in emails sent to subscribers of your Page.
Send from Email: The email address used for Status Page notifications. It is possible to send from your own domain. See this article for assistance creating or editing your SPF Record.
Reply To Email: Allow subscribers to reply to this email address (e.g. firstname.lastname@example.org).
Components represent the functional parts of your infrastructure, such as websites, API endpoints, or databases. They are not required to be linked to a check created within Uptime.com, nor are they required to complete the creation of your Page setup.
Some examples of components include:
- Your home page or application
- Support staff members onsite
- A web server
- API endpoints
- A third party online resource
Not all of the above examples are IT resources, but components generally represent the essentials behind a business or service. This includes internal components, which may not be monitored by Uptime.com.
A component or component group can be in one of the following statuses at a given time:
- Operational - Component is operating as intended, which is the default state
- Major Outage - The component is not available
- Partial Outage - The outage is partial and may affect users sporadically
- Degraded Performance - Performance is degraded, but no outages are detected
- Under Maintenance - In maintenance state
If a Component is a single resource necessary to your operations, Component Groups are related resources grouped together to make it easy for your visitors to inspect. Support staff from the above example could be a part of your Component Group, “Tech Support”. A group may also be a single site and all of its internal components, or set of servers per type i.e database(s), load balancer(s), or firewall(s).
Groups are most useful in providing the end user some clarity on which components are down, and setting expectations about their experience.
There are several conditions under which a component’s status can change. Administrator users can manually change a component’s status, and the Page can automatically trigger a component status change based on check state, maintenance state, or incident state as well.
Please note that components set to automatically change status will not create an incident.
A component or group will inherit the status that is most severe. Here are two examples:
If you have 5 components within a component group, while one is experiencing a Major Outage and the other four are experiencing only Degraded Performance, your Page will show this component group as experiencing a Major Outage.
If a component is set to automatically trigger a component status change based on check state, and an administrator user manually adjusts that status during the incident, the component will not return to its automated pre-set state when the incident is resolved. Additionally, the auto behaviour of the component will remain inactive until the administrator manually restores the component’s status to Operational.
Component Name: Name of component/system, e.g. Website, Database, API.
Component Group: Select an existing component group for this component. If you have not yet created a component, you will need to click + Add Group from the component tab.
Here is more information on how groups differ from single components.
Component Description: OPTIONAL: Provide a description of this component for Page visitors
Associated Check: OPTIONAL: Link this component to a check to display response time. Checks can also affect component status.
If check fails, set component status to: OPTIONAL: Automatically change component status based on check state.
When check recovers, always set the component status to: Similar to “If Check Fails…” above, this is OPTIONAL. The component status will be set to the selected option once the check recovers.
Group Name: Group related components under this heading
Group Description: OPTIONAL: Add a description visible to Page visitors beneath the name of the component group.
A System Metric, such as response time graphs, adds visibility into critical system performance on your Status Page. System metrics are required to be linked to checks associated with your Uptime.com account that report on response time. Once-per-day checks, such as Blacklist/Malware, can not be tied to a metric.
Please Note: SSL checks will not show a graph on the response time since it is a once-per-day check. Instead it will show the time until expiration.
Some examples of metrics include:
- Response time graphs
- Performance statistics
Associated Check: Link this System Metric to a check to display response time graph.
Metric Display Name: Visitors will see this name when viewing metrics for the associated check
Incidents help convey the state of downtime events to your userbase in real-time. Incidents hold the chronology of an event, from start to finish with every change in status in between. Each incident can be in one of the following statuses:
- Scheduled Maintenance
Select an incident state, and provide an optional incident description. Markdown is supported for complex formatting. Use double-spacing to begin a new line. Use the Preview button to review your incident description.
When an incident is Created, Updated, or Resolved, users have the option to Notify Status Page Subscribers of this Update, which is not selected by default. There is a delay of two minutes before the update is sent when notifying subscribers of an update to your status page.
When an incident is Resolved, users can Reset all affected components to Operational.
Note: It is possible to backdate incidents, in case you need to acknowledge downtime retroactively.
Date and Time of incident start. Leave blank to start the incident when this form is saved.
Date and Time of incident end. Leave blank if the incident is ongoing.
Please note: Incidents are rounded to the nearest minute. (i.e. 15 seconds and 35 seconds of incident downtime will both display <1 minute, while 9 minutes 59 seconds will be 10 minutes.)
This incident should count as downtime: This incident’s duration will contribute to global downtime calculations.
Components Affected: OPTIONAL: Select the component(s) affected by this incident. You can also select the status to change for the component, such as Degraded Performance or Major Outage.
Schedule maintenance windows and issue notifications to alert your subscribers of planned downtime events. Maintenance affects a component and Page in several ways.
When active, maintenance windows appear in the Current Status tab at the bottom of a Status Page. Maintenance windows can affect a component’s status, which administrators can trigger manually or as part of the automated window. Select a component, or number of components, and then select the state of those components.
Users can update these component states when maintenance begins, or change states on the fly. It is important to note a component will always inherit the most severe status.
Start and end time dictate how long your Page will display the maintenance window you set. It is possible to have ongoing maintenance by leaving the maintenance end time blank.
A maintenance window can be in one of the following statuses:
- Scheduled Maintenance
Select a maintenance state and provide an optional incident description. Markdown is supported for complex formatting. Use double-spacing to begin a new line.
Title: A name for this maintenance window.
Date and time of the maintenance window start.
Date and time of maintenance window end. Leave blank if it’s an ongoing maintenance window.
This maintenance window should count as downtime: This maintenance window’s duration will contribute to global downtime calculations.
Components Affected: OPTIONAL: Select the components affected by this maintenance window, as well as any changes in status.
Updates: Add maintenance updates throughout the scheduled window, mark as resolved to display as a past maintenance event.
Once you have made the Status Page publicly available, from the live preview, you and anyone who views this page will be able to see a Subscribe to Updates button.
Anyone who has access to the Status Page URL can subscribe to receive notifications for incidents or maintenance posted. The subscription options are:
Furthermore, your subscribers will be able to subscribe to specific components of their choice to receive updates to them. For more details, see the corresponding documentation here.
The screenshots below illustrate each of the subscription methods.
Our Custom Webhooks enable you to send alerts to any third-party system that expects to receive an application/json encoded payload in the body of a request.
Here is a sample Uptime.com subscription POST request:
"name": "Test incident",
"description": "This is an incident update",
"description": "This is an incident update",
Accounts with SSO enabled will have access to additional security measures for accessing their Status Page. To activate these two External User settings, set Visibility Level to External Users.
For further details, please see Securing Your Uptime.com Status Page.
Please note: this feature may not be available in all account tiers. If you don't find the following settings in your status page, contact email@example.com for assistance.
Secure your Status page with your SAML SSO and an external Identity Provider (IdP). This will be specific to the status page, and will require a separate IdP-side application.
Invite an external user by email to create status page-specific credentials with the Uptime.com login portal.
Some fields support Markdown for complex formatting. Below are some examples:
Emphasis, aka italics, with *asterisks* or _underscores_.
Strong emphasis, aka bold, with **asterisks** or __underscores__.
Combined emphasis with **asterisks and _underscores_**.
Strikethrough uses two tildes. ~~Scratch this.~~
1. First ordered list item
2. Another item
⋅⋅* Unordered sub-list.
* Unordered list can use asterisks
- Or minuses
+ Or pluses
Want to see our checks in action? Check out our YouTube Library for more!