Websitemonitoring voor ontwikkelaars, vast verankerd in uw stack.
Uptimia voert uw echte API-aanroepen uit — inloggen, token ophalen, bestelling plaatsen, terug uitlezen — en controleert elke respons met assertions. Geef elke cronjob een heartbeat-URL, maak monitors aan vanuit uw deployscript, en word gealarmeerd in Slack, Discord of PagerDuty.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sVier storingen die nooit een fout gooien
Alle vier kloppen op de dag van een deploy. Geen enkele blijft uit zichzelf waar — en zodra er een niet meer klopt, gooit niets een fout.
"Als er iets kapot ging, zouden we een exception zien."
Errortrackers zien alleen code die draait. Een cron-invoer die nooit start, een worker die halverwege een job vastloopt, een certificaat dat stilletjes verloopt — geen van alle gooit een fout. De ergste storingen zijn geen stacktraces; het is stilte.
"De pipeline is groen, dus productie is in orde."
CI bewijst dat de code goed was op het moment van deployen. Verlopen tokens, volle schijven, uitgeputte quota's en configuratie die uit koers raakt gebeuren allemaal tussen deploys door — in het draaiende systeem dat uw testsuite nooit meer terugziet.
"Dat zouden we snel merken — we zijn de hele dag online."
U zit 40 van de 168 uur in de week achter een toetsenbord — de andere 128 kijkt niemand. En gebruikers melden een kapotte checkout zelden; ze proberen het één keer opnieuw en vertrekken.
"Het werkte in staging, dus het werkt."
Staging heeft nooit het verkeer, het datavolume, de quota's van derden of de DNS van productie. De storingen die u om 03:00 uur wakker bellen, zijn precies degene die staging niet kan nabootsen.
"We hebben een /health-endpoint — we zitten dus goed" is de grootste. Een health-check van één minuut vertelt u 1.440 keer per dag dat een proces reageert (24 × 60). Het aantal van die controles dat bewijst dat de checkout wordt afgerond, de nachtelijke back-up draaide of de wachtrij leegloopt: nul.
"Een proces reageert" en "het systeem werkt" zijn verschillende beweringen — en maar één daarvan is degene waar uw gebruikers om geven.
Zo ziet een stilletjes gestorven cronjob eruit wanneer er een heartbeat naar luistert.↓ minuut voor minuut
Wat er gebeurt als een cronjob stilletjes stopt
Een deploy herschreef de crontab en liet één regel vallen. Die nacht startte de invoice-worker niet, wierp geen fout, en elk dashboard bleef groen — de wachtrij kwam nooit in beweging.
Dat dekt de job die stierf. Maar cron is maar één van de oppervlakken die geluidloos falen — elke aanname hierboven heeft er zijn eigen versie van.↓ een monitor voor elk
Ketens, pings en agents
API-ketens voor diensten, inkomende pings voor jobs, echte-browserflows voor checkouts, een eenregelige agent voor de machine. Verschillende oppervlakken, één incidentstroom, één API.
Ketens, heartbeats en escalatieladders
Geketende aanroepen, per stap gecontroleerd
Een /health-endpoint bewijst dat een proces reageert. Over de flow erachter bewijst het niets. De keten voert de echte aanroepen op volgorde uit en controleert elke respons — de statuscode, de duur, een waarde in de JSON — zo vaak als eens per minuut op elk betaald pakket, vanaf elke locatie of alleen de locaties die u kiest.
- Tot 15 stappen — GET, POST, PUT, PATCH, DELETE of HEAD, op volgorde uitgevoerd
- Extraheren en hergebruiken — haal een waarde uit één respons en gebruik die met
{{token}}in de volgende - Controleer wat ertoe doet — statuscode, responstijd, een JSONPath-waarde, een header of body-tekst, per stap
/health-controle reageert de hele tijd prima — en bewijst geen van deze vier aanroepen.
0 van 4 bewezen
De job die nooit gestart is
Een job die stopt met draaien wordt stil, niet rood — er gaat geen fout af, dus er wordt niets gewaarschuwd. Geef hem een heartbeat-URL om te pingen wanneer hij draait, en de ontbrekende ping wordt het alarm: mist hij het venster voorbij de respijtperiode, dan opent Uptimia een incident. Signaleer ook start en einde, en het vangt jobs op die blijven hangen in plaats van te stoppen.
- Interval of cron-schema — een eenvoudig interval of een 5-veld cron-expressie in de tijdzone van uw account
- Eén regel om aan te sluiten — kant-en-klare snippets voor Crontab, Bash, PowerShell, GitHub Actions en PHP
- Vangt hangers op, niet alleen misses — stuur een startping en een looptijdlimiet markeert een job die nooit klaar is
Monitors aangemaakt vanuit uw deploystap
Niemand klikt ergens op — het script dat de dienst uitrolde, maakte zijn eigen monitor aan. Maak en beheer monitors via de REST-API vanuit een CI-stap, en zodra een incident opent, POST't een aangepaste webhook het naar wat u toch al gebruikt: een statusbord, een bot, een ChatOps-flow.
- Een REST-API — monitors aanmaken, lezen, bijwerken en verwijderen op elk pakket (API-monitors en heartbeats leven op v2), met API-sleutels van uw account beheerd in de instellingen
- Aangepaste webhooks — POST een vaste JSON-body met uw eigen headers naar elk endpoint bij een monitor-gebeurtenis
- Standaard veilig — de aflevering van webhooks is TLS-geverifieerd, pint DNS op het moment van verzenden en weigert doelen in privénetwerken
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
Eerst Slack, PagerDuty als niemand bevestigt
In het kanaal dat uw team al in de gaten houdt, niet een inbox die 's nachts niemand opent. De escalatieladder tilt een onbeantwoorde Slack-ping op naar een PagerDuty-oproep volgens uw schema, en één bevestiging — getikt in de waarschuwing zelf, zonder in te loggen — pauzeert elke openstaande stap voor iedereen.
- Waarschuwingen waar u werkt — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, e-mail, sms, webhooks en meer
- Escalatieladders — tot 10 getimede stappen per beleid; bevestig vanuit de waarschuwing en de ladder pauzeert
- Eerst bevestigd — storingen worden vanuit meerdere regio's geverifieerd — en late jobs voorbij hun respijtperiode — voordat iemand wordt gealarmeerd
Gealarmeerd waar u al werkt, niet in weer een ander dashboard
Een worker die stopte, een keten die brak, een machine zonder schijfruimte — het bereikt allemaal dezelfde kanalen, en het is allemaal scriptbaar via de REST-API.
Microsoft TeamsEén contactlijst — eenmalig instellen via de API of de interface.
Bekijk de volledige integratielijst →Een kapotte deploy hoort u te alarmeren.Niet uw gebruikers.
De 30-daagse proefperiode ontgrendelt elk monitortype en elk waarschuwingskanaal.
Uw eerste monitor instellen in drie stappen
Richt hem op een oppervlak, route de waarschuwing, en laat hem draaien.
Kies het oppervlak
Een API-keten, een heartbeat-URL, een browserflow of de eenregelige agent — maak hem aan in de interface of via de REST-API.
Route de waarschuwing
Stuur hem naar Slack, Discord of PagerDuty, voeg een webhook toe, en bepaal wie als volgende wordt gealarmeerd als niemand bevestigt.
Laat hem draaien
Controles draaien vanuit 171+ probes en bevestigen een fout voordat u wordt gealarmeerd — met vermelding van de stap of job die kapot ging.
Ook inbegrepen
Eenregelige server-agent
CPU, geheugen, schijf en load van binnenuit de machine — een bash-installatie met checksumverificatie, geen collector om zelf te schrijven. Linux, via een systemd-timer of cron.
Transactiemonitoring
Speel een login of checkout opnieuw af in een echte browser — stap voor stap gebouwd in de builder, met een schermafbeelding van wat elke stap zag.
Onderhoudsvensters
Vanavond deployen? Plan het onderhoudsvenster — controles pauzeren, waarschuwingen blijven stil, geen vals alarm tijdens een geplande release.
Herstelmeldingen
Wanneer een dienst terugkomt, horen de mensen die gealarmeerd werden dat ook — geen aanhoudend "ligt hij nog plat?" in het kanaal.
Incidentgeschiedenis
Elk incident wordt vastgelegd met wat afging, wanneer, hoe lang het herstel duurde en — waar een escalatieladder draait — wie bevestigde.
Eén lijst voor ketens en jobs
API-ketens, heartbeats, servers en uptime-controles delen één dashboard, één waarschuwingsruggengraat en één API — geen vier losse tools.
Wat is websitemonitoring voor ontwikkelaars?
Websitemonitoring voor ontwikkelaars is het bewaken van de oppervlakken die u uitrolt — HTTP-API's, achtergrondjobs, servers en gebruikersflows — en het alarmeren via de tools die u al gebruikt zodra er één kapot gaat. U verankert monitoring in de stack: een meerstaps-API-controle van buitenaf, een heartbeat-ping die een cronjob binnenstuurt, een agent in de machine, en een REST-API en webhooks waar u liever scriptmatig werkt.
Hij reageert, en toch is het kapot
Een oppervlakkige ping blijft groen terwijl de flow waarvan uw gebruikers afhankelijk zijn, faalt.
De keten vangt het op
De assertion die faalt, noemt de exacte aanroep — u begint met debuggen, niet met gokken.
Welke monitor bewaakt wat
Elke familie bewaakt een ander oppervlak — allemaal met één dashboard, één waarschuwingsruggengraat en één REST-API. Elke familie wordt ook apart geteld, en een keten is de duurste regel om te draaien — de prijspagina bevat de cijfers per pakket.
Bekijk alle monitortypen →| Oppervlak | Wat het signaleert | Hoe het werkt |
|---|---|---|
| API-keten | Kapotte meerstapsflows | Tot 15 geordende stappen met assertions per stap, gecontroleerd zo vaak als eens per minuut |
| Heartbeat | Crons & workers die geluidloos stoppen | Inkomende ping-URL; een gemist venster voorbij de respijtperiode opent een incident |
| Uptime | Storingen, serverfouten | Controles van buitenaf zo vaak als elke 30 sec. op Professional en hoger, bevestigd vanuit tot 3 regio's |
| Server-agent | CPU-, geheugen-, schijfdruk | Eenregelige Linux-agent die elke 30 sec. /proc + df rapporteert |
| Transactie | Kapotte logins & checkouts | Meerstapsflows opnieuw afgespeeld in een echte browser |
FAQ over monitoring voor ontwikkelaars & DevOps
01Wat is websitemonitoring voor ontwikkelaars?+
02Kan ik een meerstaps-API-flow bewaken, niet alleen één endpoint?+
{{token}} in de volgende, en controleer per stap op statuscode, responstijd, een JSONPath-waarde, een header of body-tekst. Faalt een stap, dan noemt de waarschuwing hem — u weet welke aanroep brak.03Hoe bewaak ik een cronjob of achtergrondworker?+
curl toe zodat hij pingt bij elke run. Stel een interval of cron-schema in met een respijtperiode, en komt de ping niet binnen, dan opent er een incident. Een startping plus een looptijdlimiet vangt ook jobs op die blijven hangen. Snippets zijn er voor Crontab, Bash, PowerShell, GitHub Actions en PHP.04Is er een uptime-monitoring-API om monitors aan te maken en te beheren?+
curl-voorbeeld om te kopiëren. Er is geen Terraform-provider of Zapier-app.05Kan ik elk teamlid een eigen API-sleutel geven?+
06Waar komen waarschuwingen terecht, en kan ik ze doorsluizen naar mijn eigen tools?+
07Regelt u wachtdienstroosters?+
08Draait de server-agent op Windows?+
/proc en df uitleest voor CPU, geheugen, schijf en load. Een PowerShell-collector voor Windows en een voor macOS worden meegeleverd en versturen dezelfde payload — zonder de per-core- en I/O-wait-cijfers die alleen Linux levert — maar u krijgt ze niet als eenregelig commando aangereikt. Windows-hosts kunt u bovendien van buitenaf bewaken met uptime-, API- of transactiemonitors.09Kan ik een cURL-commando of OpenAPI-spec importeren in de API-builder?+
10Hoeveel ketens, heartbeats en agents zitten er in een pakket?+
Rol het uit. Wij houden het in de gaten.
Veranker een API-keten, een heartbeat en een server-agent in de proefperiode — waarschuwingen bereiken u waar u al bent.