.upptimerc.yml file is used as the central configuration for Upptime, with this syntax:
A GitHub repository is used as the "source of truth" for your uptime logs, and the static site uses the GitHub API and fetches data from this repository.
After you've created a new repository using this template (see Creating a repository from a template), specify the username and repository name in the configuration:
You can track as many websites as you like. Add the names and URLs of your endpoints in the sites key:
To make POST requests (or any other HTTP verb), you can add the method key:
If you don't want to show a URL publicly, you can use repository secrets (see Creating and storing encrypted secrets). Instead of the plain text URL, add the name of the secret prefixed with a $ character:
In the above example, a secret named
SECRET_SITE (without the $) is stored in the repository. You can add as many secrets as you like, and use them in URLs by adding the
$ prefix. For example, if your environment variable is called
API_URL, the site URL can be
You can also use these secrets as part of the URL, for example using a secret called
Similarly, you can set headers in a request like so:
If you want to send data alongside the headers, you can use the
You can add any string to the
body parameter, but make sure that you supply the relevant content-type header too.
Each API endpoint has an icon visible on the README.md file and the status website. By default, we use the GitHub Favicon Service to fetch the favicon for the domain of your endpoint (with a fallback to a generic globe icon), but you can also provide a custom icon URL, preferably a transparent square PNG:
If you, for example, expect a
404 response (which is traditionally an error response), you can set it as
expectedStatusCodes to mark your site as up. By default, all 20x and 30x responses are as
Maximum response time
Upptime endpoints can be up, down, or degraded. By default, if an endpoint takes more than 30 seconds to respond, its performance is tracked as "degraded". You can customize the maximum response time:
In the above example, this endpoint will be measured as degraded if it takes more than 5 seconds to respond.
Self-signed SSL certificates
If you're using a self-signed SSL certificate, you can set the
__dangerous__disable_verify_peer option to
true to skip verifying the certificate:
If you don't want to check for certificate name mismatches, you can set the
__dangerous__disable_verify_host option to
true to skip verifying the certificate:
Alternately, you can disable both of the above settings using
Custom status detection
In some cases, your endpoint may return a 200 response but you show the user an error message. This is not a recommended approach, but you can add custom strings to check for.
In the above example, if the body HTML response includes the string "File not found", the site will be marked as "down". Similarly, you can use
__dangerous__body_degraded to mark the site as "degraded" instead.
You can add services to send downtime notifications to, such as SMS, Slack, or email. For more information about notifications, visit the Notifications docs page. You can directly configure the notifications in repository secrets (environment variables).
You can add members of your team to be assigned to every downtime issue:
If you want particular users to be assigned per-site, you can add assignees under each entry in sites:
A static website with PWA is also generated, and you can customize the logo and name in the navbar:
If you want to add a custom domain, you can add the cname key:
If you're not using a custom domain, you should add the base URL to support the default GitHub Pages URL.
Then, your status page may be hosted on https://user.github.io/repo/, where
user is your GitHub username and
repo is your repository name.
You can customize the navbar by adding or removing top-level navigation links.
Optionally, you can add some introductory text to the website. You can use Markdown:
You can add custom scripts:
Or, directly add inline JS:
You can add custom stylesheets:
Or, directly add inline CSS:
Custom API base URL
By default, Upptime uses the official GitHub API to fetch data for your status page website. If you have a proxy API (perhaps using a personal access token with readonly access to your private repository), you can set the
apiBaseUrl key under
Though our status page is in English, you can use any language with Upptime by supplying the required strings. The list of all required strings is available in
upptime/status-page/i18n.yml, and you can add them under the i18n key in the configuration file:
You can, for example, change the footer copyright text by changing the internationalization key for
footer. These i18n keys are also used for your README.md file.
Similarly, you can also localize the
README.md file by adding these to the same
i18n.yml file: List of README.md strings.
If you've just set up your new repository and don't have repository metadata (like description, topics, and homepage), Upptime will update that for you. It will update the metadata as follows:
- Description: "📈 Uptime monitor and status page for $TITLE, powered by @upptime", where $TITLE is the name of your GitHub organization or user
- Topics: "uptime-monitor", "status-page", "upptime"
- Homepage: Link to your status website
You can add these configuration properties if you don't want these updates to occur:
Git commit options
Upptime commits to git history to keep a track of response times, and also commits graphs and README updates. You can change the commit messages for each of these actions:
By default, these commits are done by Upptime Bot, but you can overwrite these commits to use your bot instead.
You can customize the schedule when Uptime workflows run by adding the
workflowSchedule key in your configuration file. The default values and syntax is like so:
Requests made to the GitHub API must include a valid User-Agent header (see User Agent required). It is recommended to use your GitHub username here: