Monitoring in the portal shows every site you can see on one page: whether it is answering, how fast, when its certificate runs out, its last deploy and backup. It has three tabs: Health, Incidents and Activity. Open it from the sidebar, or go to Monitoring.
Whether the veldhost platform itself is up is a separate question, answered on the public status page. Uptime, the status page and the SLA explains that page and what we commit to.
Read the Health tab
At the top is one sentence about all your sites, such as All 3 sites up or 1 site needs attention. A site only counts as up when a recent health check saw it answer. Next to the sentence you see how many sites are not checked yet or stale, the number of open incidents, and when the last check ran.
A site's state is one of these:
- Online: a recent check saw it answer.
- Needs attention: the last check failed, or the site failed to set up.
- Not checked yet: the health check has not reached it yet. Checks start within minutes of a site going live.
- Stale: there has been no check result for a while, so we don't know. This is a gap in our checks, not an outage on your site, and it is not counted as one.
- Setting up, Paused or Removing: the site is not live, so it is not checked.
Below the sentence is a row of figures for all your sites together:
- Uptime 30d: the share of health checks over the last 30 days that found your sites answering, with the number of checks and failures. It shows — until there is a first check. A site with no history is never shown as 100%.
- Slowest p50 · 24h: the median response time of your slowest site over the last 24 hours, and which site that is.
- Server errors · 24h: 5xx responses across all your sites. A 4xx (not found, refused) is your site turning a request away. That is the site working, so it is not counted here.
- Next TLS expiry: the certificate that runs out first.
- Deploys · 7d: deploys started in the last 7 days. It turns red only while a site's most recent deploy has failed. Click it to see those deploys in Activity.
- Backed up · 24h: how many of your sites with backups have a recent one.
Under that, three short lines:
- Platform: the current state of the veldhost platform, with a Status page › link.
- Alerts go to: your own email address, while your Outages or Deploys emails are on, and the Slack, Teams or webhook integrations you added that listen for
site.downordeploy.failed. The emails themselves go to each site's creator and the account's owners and administrators (see Choose which emails you get). If it says Email off · turn on, you have switched both email categories off. See Choose which emails you get. - Status pages: how many of your sites have a public status page switched on. Use Manage ▾ to open them or turn them on. See Your public status page, badge and feeds.
The Sites table has one row per site: Status, Uptime 30d, Response (the 24-hour median), a bar for the Last 30 days, TLS (days left on the certificate), Last deploy and Last backup. Choose 90 d on a row to see its last 90 days. The ⋯ menu on each row opens the site page, its Deploys tab, its Activity, the live site and its public status page, if it has one.
The page refreshes by itself while you have it open.
Note: If you have apps that we manage for you, you also see a Managed apps table, with five checks per app: Website, SSL certificate, Backups, Background jobs and Scheduled tasks. A Needs your attention list above the sites shows their open alerts.
Follow an incident
An incident is a problem that veldhost staff have opened and are working on, such as an outage or slow responses, and that affects one or more of your sites. You can't open incidents yourself. If something is wrong and there is no incident for it, contact support.
- Open Monitoring → Incidents. If there are open incidents, the tab shows how many.
- The figures at the top show how many incidents are Active (open, under investigation or being monitored), how many are Critical or high, how many were resolved in the last 7 days, and the Mean time to resolve over the last 30 days.
- Narrow the list with All statuses, All severities and All sites. Clear filters resets them. Active incidents come first, then Resolved · most recent first.
- Click an incident's title, or choose Open incident from its ⋯ menu, to see its Summary, a Timeline of updates, and the Affected sites.
An incident's status is Open, Under investigation, Being monitored or Resolved. Severity is Critical, High, Medium or Low. You only see incidents that affect a site you can see, and only the updates we share with you. Updates are signed "veldhost".
To get incidents by email or in a feed reader, subscribe on the site's public status page, once it is switched on. To get them in Slack, Teams or your own endpoint as incident.opened and incident.resolved events, add a webhook or Slack integration.
See what changed: the Activity tab
Activity is a timeline of what happened to your sites and domains, newest first, in plain words:
- deploys
- nightly and on-demand backups
- restores
- sites going down and coming back
- domains going live, or still waiting for your DNS
- certificates that could not be issued
- people added to your team, and invites
- incidents
- migrations
- account changes from the audit log
Filter by site, or by Last 24 hours, Last 7 days, Last 30 days or Last 90 days. Repeats of the same event are folded into one line, which you can open. Load more shows older events. The list has a ceiling. When you reach it, the page says so: pick a single site or a shorter period to see the rest.
For a record of every sign-in and change made with your own login, use the audit log instead.
From the API or an AI assistant
GET /api/v1/sites/SITE_SLUG/health returns the latest health check result and when it ran (health_is_fresh tells you whether it is recent enough to trust). It also returns the deploy state and any open incidents for that site. It works on sites that are suspended or still setting up, so you can diagnose a site that is down. GET /api/v1/apps/SITE_SLUG/incidents lists that site's incidents, open and resolved. Both need only the read scope. An assistant uses get_site_health for the same thing. See the API and MCP tools.