Skip to content

Configuration

lyc8503 edited this page Nov 5, 2025 · 17 revisions

All of UptimeFlare's configuration is done in the uptime.config.ts file, and after you create your own UptimeFlare repository from a template, you will need to modify the uptime.config.ts in your repository to define the monitoring and other configurations you need.

It is a typescript file, but when used as a configuration file, it is similar to JSON.

The uptime.config.full.ts file provided in the template is the latest complete configuration, usually, you don't need to use all the options, below I will explain some of the commonly used configurations and provide a simpler configuration as a reference.

PageConfig

PageConfig is mainly status page related configuration items, including the title of the status page, and the link in the upper right corner of the status page.

These configurations are literally just that, modify them as you see fit!

const pageConfig: PageConfig = {
  title: "lyc8503's Status Page",
  links: [
    { link: 'https://github.com/lyc8503', label: 'GitHub' },
    { link: 'https://blog.lyc8503.site/', label: 'Blog' },
    { link: 'mailto:me@lyc8503.site', label: 'Email Me', highlight: true },
  ],
}

WorkerConfig

WorkerConfig is mainly used in the worker for monitoring, the main monitors are defined in the monitors array.

notification contains configuration related to sending notifications, if you need to be notified when the monitoring status changes, see Setup notification.

If you want to make your status page private (of course it's optional), you may set up a username and password by providing passwordProtection.

const workerConfig: WorkerConfig = {
  passwordProtection: 'username:password',
  monitors: [
    {
      id: 'foo_monitor',
      name: 'My API Monitor',
      method: 'GET',
      target: 'https://www.google.com'
    },
    {
      id: 'test_tcp_monitor',
      name: 'Example TCP Monitor',
      method: 'TCP_PING',
      target: '1.2.3.4:22'
    },
    // You can continue to define more monitors here...
  ],
  notification: {
    //...
  },
}

The complete configuration for a single monitor is as follows, if you don't know what a field is for, don't include it!

{
  // `id` should be unique, history will be kept if the `id` remains constant
  id: 'foo_monitor',
  // `name` is used at status page and callback message
  name: 'My API Monitor',
  // `method` should be a valid HTTP Method
  method: 'POST',
  // `target` is a valid URL
  target: 'https://example.com',
  // [OPTIONAL] `tooltip` is ONLY used at status page to show a tooltip
  tooltip: 'This is a tooltip for this monitor',
  // [OPTIONAL] `statusPageLink` is ONLY used for clickable link at status page
  statusPageLink: 'https://example.com',
  // [OPTIONAL] `hideLatencyChart` will hide status page latency chart if set to true
  hideLatencyChart: false,
  // [OPTIONAL] `expectedCodes` is an array of acceptable HTTP response codes, if not specified, default to 2xx
  expectedCodes: [200],
  // [OPTIONAL] `timeout` in millisecond, if not specified, default to 10000
  timeout: 10000,
  // [OPTIONAL] headers to be sent
  headers: {
    'User-Agent': 'Uptimeflare',
     Authorization: 'Bearer YOUR_TOKEN_HERE',
  },
  // [OPTIONAL] body to be sent
  body: 'Hello, world!',
  // [OPTIONAL] if specified, the response must contains the keyword to be considered as operational.
  responseKeyword: 'success',
  // [OPTIONAL] if specified, the response must NOT contains the keyword to be considered as operational.
  responseForbiddenKeyword: 'bad gateway',
  // [OPTIONAL] if specified, will call the check proxy to check the monitor, mainly for geo-specific checks
  // refer to docs https://github.com/lyc8503/UptimeFlare/wiki/Check-proxy-setup before setting this value
  checkProxy: 'https://xxx.example.com OR worker://weur',
  // [OPTIONAL] if true, the check will fallback to local if the specified proxy is down
  checkProxyFallback: true,
},

MaintenanceConfig

This configuration is intended for the Scheduled Maintenance feature. Even if you don't need this feature, please add at least the following line, otherwise the deployment may fail.

const maintenances: MaintenanceConfig[] = []

If you want to use this feature, you can configure scheduled maintenance events like the following. You can configure multiple events without deleting the previous ones.

const maintenances: MaintenanceConfig[] = [
  {
    // [Optional] Monitor IDs to be affected by this maintenance
    monitors: ['foo_monitor', 'bar_monitor'],
    // [Optional] default to "Scheduled Maintenance" if not specified
    title: 'Test Maintenance',
    // Description of the maintenance, will be shown at status page
    body: 'This is a test maintenance, server software upgrade',
    // Start time of the maintenance, in UNIX timestamp or ISO 8601 format
    start: '2025-04-27T00:00:00+08:00',
    // [Optional] end time of the maintenance, in UNIX timestamp or ISO 8601 format
    // if not specified, the maintenance will be considered as on-going
    end: '2025-04-30T00:00:00+08:00',
    // [Optional] color of the maintenance alert at status page, default to "yellow"
    color: 'blue',
  },
}

Clone this wiki locally