Raggruppamento logico dei servizi
Raggruppa i monitor in servizi con un nome — API pagamenti, flusso checkout, autenticazione — così il team ragiona in termini di servizi, non di singoli URL e porte.
Catalogo dei servizi
Ogni servizio, ogni owner,
Ogni servizio, ogni owner,
ogni dipendenza.
Un inventario aggiornato di ogni servizio gestito dal team: owner attuale, chi è in reperibilità in questo momento, dipendenze upstream, link a dashboard e runbook, e stato di salute a colpo d'occhio — tutto in un unico posto.
Free tier included
No credit card
2-minute setup
payments-service HealthyLIVE
IN REPERIBILITÀA. Patel
INCIDENTI APERTI0
DIPENDENZE4
checkout-api95ms
stripe-gateway88ms
postgres-primary72ms
redis-cache60ms
fraud-service45ms
Cosa ottieni
Smettila di chiederti "chi gestisce questo?"
Il Catalogo dei servizi è la risposta autorevole a ownership, copertura di reperibilità, dipendenze e stato di salute attuale per ogni servizio nel tuo stack. Collega monitor, incidenti, policy di escalation e runbook in un'unica vista operativa.
Ownership e reperibilità a colpo d'occhio
Ogni servizio ha un team owner e un calendario di reperibilità collegato. Una singola pagina indica chi è responsabile e chi allertare in questo momento — senza inseguire le persone su Slack.
Mappatura delle dipendenze
Registra le dipendenze upstream e downstream così i responsabili della risposta comprendono immediatamente il raggio d'impatto quando un servizio degrada. Niente più archeologia post-incidente per capire cosa dipende da cosa.
Runbook, dashboard e repository
Collega runbook, dashboard, repository del codice e wiki direttamente a un servizio. Tutto ciò di cui un responder ha bisogno è a un clic di distanza durante un incidente in corso.
Routing automatico degli incidenti
Gli incidenti creati su un servizio vengono instradati automaticamente attraverso la policy di escalation del servizio, senza assegnazione manuale. Il team giusto viene sempre allertato.
Integrazione con le pagine di stato
Collega un servizio a un componente sulla tua pagina di stato pubblica. Quando viene creato un incidente, lo stato del componente si aggiorna automaticamente, mantenendo gli utenti informati senza passaggi aggiuntivi.
01 · Stato di salute a colpo d'occhio
Una vista per la salute di
Una vista per la salute di
ogni servizio.
La homepage del catalogo mostra lo stato di salute attuale di ogni servizio — verde, degradato o inattivo — derivato dai dati live dei monitor. Durante un incidente è la prima schermata che il team apre per comprendere portata e impatto prima di approfondire.
- Salute derivata in tempo reale dallo stato dei monitor collegati
- Numero e gravità degli incidenti aperti mostrati per ogni servizio
- Salute delle dipendenze visibile a un livello di profondità nella scheda servizio
Service Catalog Partial OutageLIVE
SERVIZI18
DEGRADATI2
INCIDENTI APERTI1
payments-service95ms
checkout-api88ms
auth-service12ms
cdn-edge75ms
email-service60ms
02 · Gestisci come codice
Provisiona il catalogo
Provisiona il catalogo
dal tuo repository.
Definisci servizi, owner, dipendenze e assegnazioni di policy tramite REST API. Inserisci le chiamate in uno script del repository e le modifiche passano attraverso il normale processo di pull request — revisionate, approvate, applicate — così nessuno aggiorna il catalogo manualmente dall'interfaccia.
- CRUD completo dei servizi tramite REST API
- Link a policy e calendari versionati insieme alla configurazione del servizio
- Diff-friendly: la revisione della PR mostra esattamente cosa è cambiato
register a service$ curl -X POST https://api.siteqwality.com/service/ \
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"payments-service","owner_team":"payments-squad","escalation_policy_id":"$EP","on_call_schedule_id":"$SC","runbook_url":"https://wiki.acme.internal/payments/runbook"}'
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"payments-service","owner_team":"payments-squad","escalation_policy_id":"$EP","on_call_schedule_id":"$SC","runbook_url":"https://wiki.acme.internal/payments/runbook"}'
1
posto per owner, reperibilità e salute di ogni servizio
0
passaggi manuali per instradare un incidente al team giusto
N
livelli di dipendenze visibili per ogni scheda servizio
$0
piano gratuito — catalogo dei servizi incluso fin dall'inizio
FAQ
Questions, answered.
Un servizio è un'unità logica con un nome che raggruppa uno o più monitor, ha un owner, è collegato a una policy di escalation e a un calendario di reperibilità, e opzionalmente si associa a un componente della pagina di stato. È il modo in cui il team pensa all'infrastruttura, non come è fisicamente organizzata.
La salute viene derivata dai monitor collegati al servizio. Se un monitor è in errore, il servizio appare come degradato o inattivo. Numero e gravità degli incidenti aperti vengono mostrati insieme al segnale di salute derivato dai monitor.
Sì. Puoi indicare dipendenze upstream e downstream per ogni servizio. Durante un incidente, la pagina di dettaglio del servizio mostra se alcune delle sue dipendenze sono anch'esse degradate, aiutando i responder a comprendere immediatamente il raggio d'impatto.
Sì. Collega un servizio a un componente sulla tua pagina di stato pubblica. Quando viene dichiarato un incidente sul servizio, lo stato del componente si aggiorna automaticamente, e alla risoluzione dell'incidente il componente torna a "Operativo".
Sì — ogni campo del catalogo (owner, policy di escalation, calendario di reperibilità, URL del runbook, link alle dipendenze) è configurabile tramite REST API. Inserisci le definizioni JSON nel repository e la normale revisione delle pull request le applica.
More of the platform
Explore the rest of the platform
Pronto?
Inizia a monitorare in meno di un minuto.
Ogni prodotto parte gratuitamente — uptime, cron, synthetic, log, RUM, incidenti e pagine di stato. Nessuna carta di credito richiesta.