Dashboard hosting for pages built on somebody else's data.
A dashboard is a display over a feed you do not control. Its two failure modes are showing yesterday's figures and hammering an API into a rate limit.
The data is not yours.
Every design decision follows from the numbers arriving from an upstream service with its own limits and its own bad days.
Refresh on a schedule, not on a visit
Fetching upstream data during a page load ties your response time to somebody else's API and multiplies your call volume by your traffic. Refreshes run on a timer instead.
One fetch serves every visitor
A thousand people viewing the same chart should produce one upstream request, not a thousand. That is the difference between a working integration and a revoked key.
A last-known value when the feed fails
Upstream outages are certain. A dashboard should show the most recent figure with its timestamp rather than an error or a blank chart.
Charts rendered server-side where possible
Sending raw series to the browser and drawing them there is slow on the devices that most often view dashboards on the move.
Historical series that stay queryable
Dashboards accumulate time-series data indefinitely. Those tables are indexed by time range because that is the only way anybody queries them.
Your uptime includes theirs.
A dashboard's reliability is the product of your own and every feed it depends on. The only way to improve that is to stop depending on the feed being up at the moment of a page load.
- Upstream fetches on a schedule rather than per request
- One fetch shared across all visitors
- Stale value shown with a timestamp on failure
- Time-series tables indexed by range
Fast even when the feed is not.
The measurement worth having is page speed while the upstream API is slow, because that is the condition the design exists for.
What we change for data dashboards
Each row separates your page's availability from the availability of the data it displays.
| Setting | What we do | Why |
|---|---|---|
| Upstream fetching | Scheduled refresh rather than fetch-on-request | Calling an API during a page load means your response time is theirs and your call volume is your traffic, which is how integrations get rate limited. |
| Fetch sharing | One upstream request per interval regardless of visitors | A thousand viewers of the same chart producing a thousand upstream calls is the behaviour that gets an API key revoked rather than throttled. |
| Failure behaviour | Last-known value shown with its timestamp | Upstream outages are inevitable, and a stale number honestly labelled is more useful than an error or an empty chart. |
| Rendering split | Series prepared server-side rather than shipped raw | Dashboards are often opened on phones, where drawing a large series in the browser costs more than sending the finished view. |
| Time-series indexing | Indexed by time range | Historical data accumulates forever and is only ever queried as a window, so an index on anything else is an index nobody uses. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Should I fetch API data on each page load?
What should the dashboard show when the feed is down?
Why is my dashboard slow on mobile?
How much historical data can it hold?
Stay up when the feed does not.
Move the dashboard across. Migration is free, refresh schedule reviewed.