This article will define the fields and forms used in your Page. Many of these components appear in all versions of a Status Page, whether Internal Status Page, Public Status Page, or Public SLA. Together, these components provide control over everything from the systems your Page will display to the look and feel of your Page, and how your visitors will interact with it.
- Status Page Settings
- 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 or subscribe for email notifications 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.
URL Slug: This is the URL path/foldername that you can customize (letters, numbers, and hyphens only).
CNAME: OPTIONAL: Create a CNAME 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.
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.
Upload Favicon: A favicon that will act as the icon of your Page in the browser tab. Favicons must not exceed 192x192 px.
Google Analytics Property ID: Your google analytics property ID, such as UA-12345678-1
Contact Email Address: Allow Page visitors to report issues to this email address (e.g. firstname.lastname@example.org).
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.
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. email@example.com).
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 preset state when the incident is resolved. Additionally, the auto behavior 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: OPTIONAL: Automatically change component status based on check state.
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.
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.
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