Miterl in Practice: From Basics to Power Use
A 3-step guide for web agencies running client sites: get started in 5 minutes, embed Miterl into your operations, and turn it into a competitive edge.
Why agencies need Miterl
If you operate sites after delivery, you should be the first to know when something goes down or an SSL certificate expires — not your client. Every time a client tells you the site is broken, your trust takes a small hit.
Miterl is built for the operations work that follows delivery. Per-client monitoring, scheduled maintenance windows, monthly reports, branded status pages, plus engineer-led incident investigation — all the tools an agency needs, bundled together.
Clients tell you first
Avoid the situation where the client notifies you that the site is down, eroding trust each time.
Spreadsheets stop scaling
At 10–20 active maintenance contracts, tracking SSL expiry and incident history in a spreadsheet stops working.
Hard to justify retainer fees
Charging a monthly maintenance fee with nothing visible to show for it leads to constant pricing pressure.
How to use this guide
Read top to bottom, or jump to any step. Each section has a “Try it in the dashboard” link — open the dashboard alongside this guide as you go.
First use
Get one client site monitored, with Slack alerts and a public status page, in 5–10 minutes.
Operations
Organize multiple clients, add maintenance windows, route incoming investigations, send monthly reports, and white-label everything.
Power use
Pre-launch audits, release-mode monitoring, on-call drills, and API integration — the things that set you apart.
1-1. Add your first client site
Pick one site you absolutely cannot let go down. For a corporate site, an HTTP/HTTPS monitor on the homepage is the standard starting point.
Steps
- Open the dashboard → click “Add monitor”
- Choose “HTTP / HTTPS” and enter the URL (e.g. https://example-client.com)
- Name it clearly: “(Client) — Corporate site”
- Save. Monitoring starts immediately at 1–5 minute intervals
SSL certificate expiry is detected automatically. Register an HTTPS URL and you’ll get notifications starting 30 days before expiry.
1-2. Receive alerts in Slack or email
A monitor alone won’t alert anyone. Set up at least one alert contact and link it to the monitor — Slack takes about 5 minutes to wire up.
Available channels
- Email — available on every plan, multiple addresses supported
- Slack — paste an Incoming Webhook URL; route by channel if needed
- Chatwork — handy for teams that already coordinate with clients in Chatwork
- LINE — for individuals or small teams that need late-night push
After creating an alert contact, run a test send. The worst time to discover a notification doesn’t arrive is during a real incident.
1-3. Publish a status page
A status page lets your client check whether their site is up, without contacting you. That alone reduces a chunk of maintenance overhead.
Why agencies use it
- Clients self-check before reaching out — fewer support tickets
- Real-time updates during incidents — stop repeating the same status to everyone
- Auto-notify email subscribers on resolution — builds long-term trust
You’ve completed the “monitor → notify → publish” loop for one site. That alone is enough to use Miterl as a basic monitoring tool.
2-1. Organize multiple clients with client groups
As you take on more accounts, “which monitor belongs to which client” becomes a problem. Client groups let you organize monitors per account.
What you gain
- Per-client monthly reports generated automatically
- Per-account routing of alerts (Client A → Slack, Client B → email, etc.)
- Anyone joining the team can see who’s watching what at a glance
2-2. Maintenance windows to suppress false alerts
Before WordPress updates, server reboots, or DNS changes, schedule a maintenance window. Alerts are suppressed during the window — no more 2 AM pages from planned work.
Common patterns
- Recurring server maintenance — book the second Wednesday night for the year
- Release work — block off 30 minutes before and after deploys
- DNS changes — set a wider window covering propagation
2-3. Use investigation requests as your intake
When a client says “the site is slow” or “something’s broken,” intake the request through the investigation form. The form structure ensures nothing important gets missed.
Intake flow
- Client reports an issue → you create an investigation request
- Symptoms / URL / screenshots attached → Miterl side investigates
- Reply with a related incident link, and the post-mortem stays attached to history
Used as your intake channel, request history accumulates per client and speeds up future incident response.
2-4. Justify your retainer with monthly reports
At month end, Miterl can generate a report like “99.98% uptime, 1 incident, mean time to recover 12 minutes.” Attach it directly to your monthly client communication.
Where it earns its keep
- Attach to the monthly client report email — your retainer becomes self-justifying
- Use as proposal evidence — easier to upsell a richer maintenance plan
- Show historical uptime when winning the renewal
2-5. Deliver under your own brand
Display your logo and brand color on status pages and notification emails. To clients, it looks like your maintenance service — not Miterl’s.
What you can customize
- Logo upload
- Brand color (applies to status pages and notification emails)
- Hide the “Powered by Miterl” mark (Standard plan and above)
At this point, your operation can scale to 10–20 accounts without breaking. This is the foundation for monetizing maintenance as a real service line.
3-1. Pre-launch audit to catch delivery mistakes
Just before going live, scan a WordPress site for leftover noindex, blocking robots.txt, broken links, and missing meta tags. Catching these before launch is far cheaper than fixing them after.
What it checks
- Leftover meta robots / X-Robots-Tag noindex
- Crawler-blocking robots.txt
- Internal broken links / image 404s
- HTTPS, mixed content, key meta tags
3-2. Release mode — “watch closely for 30 minutes”
The 30 minutes after a production release is when most issues surface. Release mode tightens the check interval to 30 seconds for that window and produces a focused report when it ends.
How to use it
- Open the monitor and click “Start release mode”
- Deploy as usual — Miterl polls aggressively
- Review the report afterward and share it in Slack
3-3. Train your on-call with drills
Without an actual incident, you can’t verify that alerts arrive, that someone responds, and that the playbook works. Drills inject simulated incidents to exercise your on-call rotation safely.
Drills are never shown on your public status page. They are an internal-only mechanism.
When to run them
- Onboarding new engineers to the on-call workflow
- Late-night notification reachability tests, with zero customer impact
- Annual review of incident handoff procedures
3-4. Connect to internal tools via API & Webhooks
Issue an API key and integrate Miterl with your internal admin, Notion, project trackers, and so on. Webhooks let you trigger custom actions whenever an incident fires.
Integration ideas
- Show a live monitoring widget inside your internal project dashboard
- Auto-create a ticket in your tracker the moment an incident opens
- Run pre-launch audits from CI/CD and gate production deploys on a pass
At this depth, Miterl stops being a “monitoring tool” and becomes the operational backbone of your maintenance service — robust enough to feature in client proposals.
Going deeper
This guide is journey-shaped — top-to-bottom. For detailed specifications and ad-hoc questions, see: