Add a globalpingEnabled boolean to the Monitor model so users can
opt-in to global location checks per monitor during creation/edit.
## Changes
- Add globalpingEnabled field to server types, Mongoose model,
Joi validation, and repository mappers
- Add globalpingEnabled to client Monitor type, Zod schemas for
HTTP and ping monitors, and form defaults
- Add "Global monitoring" ConfigBox with Switch toggle to the
monitor creation/edit form, visible for HTTP and ping types
- Queue helper and monitorService now check globalpingEnabled
before running Globalping checks or fetching location data
- Add translation keys for the new form section
## Benefits
- Users can selectively enable Globalping on monitors that need it
rather than running location checks on every HTTP/ping monitor
- Reduces unnecessary API usage and keeps the UI clean for monitors
that only need local checks
## Changes
- Remove per-monitor location selection — locations are now determined
globally by the tier setting in admin settings (3, 6, or 15 locations)
- GlobalpingService reads tier from settings on each check run, so
changing the tier in settings immediately affects all HTTP/ping monitors
- Add resolveLocationId() to map Globalping probe results back to
configured location IDs for proper grouping
- Export LOCATION_LABELS for human-readable location names on the client
- Remove unused locations field from Zod schemas and form defaults
- Remove per-monitor location ConfigBox from CreateMonitor page
- Fix settingsController.updateAppSettings missing try/catch
- Fix MongoSettingsRepository duplicate findOneAndUpdate call
- Use typed LocationCheckData instead of Record<string, any>
- Remove unused REVERSE_LOCATION_MAP from globalpingService
## Benefits
- Changing the location tier in settings takes effect immediately for
all monitors without needing to edit each one individually
- Cleaner separation of concerns — location configuration lives in
settings, not scattered across monitors
- Human-readable location labels shown in uptime details tabs
## Changes
### Server
- Expand LOCATION_MAP to support city/country-level locations for the
15-location tier (US East/West, Toronto, London, Frankfurt, Amsterdam,
Warsaw, Tokyo, Singapore, Mumbai, Sydney, Brazil, Santiago, Johannesburg,
Dubai)
- Add globalpingLocationsTier field to Settings type, Mongoose model,
repository mapper, and Joi validation (valid: 3, 6, 15, default: 6)
- Update getGlobalpingLocations endpoint to return locations based on
the configured tier from settings
- Pass settingsService to MonitorController for tier lookup
### Client
- Add tier selector (radio buttons) to SettingsGlobalping component
with descriptions for each option:
- 3 locations: North America, Europe, Asia
- 6 locations: all continents
- 15 locations: city-level global coverage
- Add rate limits info box explaining credit usage per tier:
- Without token: 250 tests/hour
- With free token: 500 tests/hour
- GitHub sponsors: higher limits
- Add all translation keys for tier labels, descriptions, and rate info
## Benefits
- Admins can choose the right balance of coverage vs API usage
- Rate limit info helps users decide whether they need authentication
The MongoSettingsRepository.toEntity method was missing the
globalpingApiKey field, causing GlobalpingService to always
report the API key as not configured.
## Changes
### Server
- Add `locations` field to Monitor model and types (up to 5 locations per monitor)
- Add `location` field to Check metadata for per-location tracking
- Add `globalpingApiKey` to AppSettings for API key management
- Create GlobalpingService that wraps the Globalping SDK to run distributed
HTTP/ping checks from multiple global locations (NA, EU, AS, SA, OC, AF)
- Extend SuperSimpleQueueHelper with fire-and-forget Globalping checks that
run alongside the existing local check without affecting the main pipeline
- Add location-aware check queries with aggregation pipeline grouping by
location in MongoChecksRepository
- Filter location checks from main uptime aggregation to preserve local check
as source of truth for status/incidents
- Extend monitor details endpoint to return per-location check data
- Add GET /globalping/locations endpoint for available location options
- Add globalpingKeySet to settings response
- Add Joi validation for locations and globalpingApiKey fields
### Client
- Add locations multi-select (Autocomplete with chips) to monitor creation
form, shown only for HTTP and ping monitor types
- Add SettingsGlobalping component for API key management (matching existing
PageSpeed pattern with set/reset flow)
- Add per-location breakdown section to uptime details page with tabs,
avg response time, uptime percentage, and response time charts
- Add globe icon with tooltip to monitor table for monitors with locations
- Add Zod validation for locations field in HTTP and ping schemas
- Add all translation keys for globalping settings, locations form, and
location details sections
## Benefits
- Users gain visibility into geographic availability and latency data
- Local check remains the source of truth, Globalping runs alongside
- Supports up to 5 locations per monitor with 6 continent-level options
- Graceful degradation when API key is not configured or rate limited
gorkem-bwl
Alex Holliday