Hourly availability checks
Each active website and subdomain is checked separately under the configured hourly schedule. A working main domain does not conceal a problem with another target.
CUSTOM SOFTWARE · FROM IDEA TO IMPLEMENTATION
I develop software that simplifies routine work and turns separate tasks into a clear, connected workflow.
Lukas Checks is my in-house system for website availability, SSL certificates and personal follow-up checks. Once the hourly schedule is configured, each active website is checked individually — not just the main domain.
Personal introductory call · no obligation · directly with Lukas Teissl
Each website individuallyHourly availability checks once configured.
SSL deadlines in viewExpiry dates, reminders and genuine follow-up checks.
Built for the taskPurposeful logic instead of unnecessary complexity.
WHY I BUILT LUKAS CHECKS
The main domain works. But what about the client portal, the landing page or a subdomain that is rarely visited? And was the certificate actually renewed, even though renewal was supposed to happen automatically?
Lukas Checks brings measurements, deadlines and follow-up checks together. Instead of opening addresses one by one and keeping separate reminders, I can see the latest finding and the next useful action in one place.
This is how I approach custom software: understand the bottleneck, think the workflow through and develop the components that genuinely make day-to-day work easier.
Open each website.
Keep separate deadlines.
Assume renewal happened.
Run scheduled checks.
See deadlines together.
Verify observed changes.
WHAT THE SYSTEM DOES
Not as many indicators as possible, but the information that matters: what was checked, which deadline is critical and what should happen next.
Each active website and subdomain is checked separately under the configured hourly schedule. A working main domain does not conceal a problem with another target.
Expiry date, time remaining, latest measurement and observed extensions appear together. Historical and unknown values remain clearly identified.
When an automatic check fails, the affected domain can be opened directly over HTTPS in a new tab. A manual browser visit does not change any recorded results.
Personal SSL checks become due at 7, 3, 2 and 1 day before expiry. Open tasks trigger daily reminders when email delivery is configured.
The browser-facing certificate and the certificate on the origin server are different checks. Without a confirmed origin configuration, no successful origin check is claimed.
Additional check paths, content rules, integrations and workflows can be planned and developed for the task. The technology follows the actual requirement.
INSIDE THE SYSTEM
Three perspectives on one workflow. These images explain the features using sample data; they do not publish internal monitoring results.
The SSL overview brings together the domain, expiry date, remaining validity, latest attempt and required action. The earliest deadlines appear first, and filters help narrow the list.
A previously verified date does not disappear after a failed check. It remains visible as the last known value, currently unconfirmed. A later expiry date can be compared clearly with the previous one.
Longer validity is an observed finding. It does not by itself prove whether the replacement was triggered automatically or manually.
Need this kind of overview for your business?
Lukas Checks evaluates each configured website independently. DNS resolution, the connection, TLS validation, the HTTP response and approved redirects are part of the public HTTPS check. Expected content can be checked as an additional rule.
The dashboard distinguishes successful measurements, problems, stale results and monitoring gaps. Unusual findings bring forward a repeat check; confirmed problems and subsequent recovery can be reported by email.
The hourly schedule needs a working webcron. Brief outages between measurements can go unnoticed, and availability does not prove every function behind a login.
Discuss monitoring for your project
Follow-up tasks become due 7, 3, 2 and 1 day before a verified expiry date. While a task is open, the system sends a daily reminder when email delivery is configured.
A successful check that you explicitly request can close the current stage. Seeing the same valid certificate is not evidence of renewal. A suitable new certificate with a later expiry provides the corresponding comparison.
Opening an email or visiting a website does not complete a check. An automatic recovery alone does not close an open personal task either.
Discuss automated follow-up
HOW THE PARTS WORK TOGETHER
The value lies in a complete workflow: observe, assess, notify and provide a next step that can be verified.
Each relevant host remains a separate target, even when several share a wildcard certificate.
No overlooked subdomainsExpected content and approved redirects help distinguish a simple server response from the configured application check.
Findings with contextA regular webcron processes only due jobs. Time limits and small batches keep the workload bounded.
Works with the browser closedProblems, recovery and open SSL checks are tracked separately. Delivery failures remain visible.
Less ambiguous noiseCSV export, a calendar file and an optional private calendar feed bring deadlines into your wider planning.
Stable calendar identifiersAn old green result does not stay current indefinitely. Missing checks are shown as monitoring gaps.
No false progressProtected administration, optional two-factor authentication and encrypted backups are part of the system.
Private data stays privateNew rules, integrations and workflows are prioritised according to their practical value.
Adaptable rather than rigidTHE TECHNICAL APPROACH
For this project, I chose a file-based PHP architecture. Installation requires neither a database server nor SSH commands. Core checks do not depend on a running AI service.
Persistent jobs, file locks, bounded execution times and traceable findings matter just as much as a clear interface. When something goes wrong, there should be a useful next step, not just a red icon.
I develop whatever the agreed solution needs, from the interface to specialised workflow logic. The focus is on practical value, not adding features for their own sake.
HOW THE SYSTEM WORKS
The application observes and records. It does not change DNS records or install or renew certificates.
Lukas Teissl
IT expert & software developer
Qualifications & credentialsTHE DEVELOPER BEHIND THE SYSTEM
Lukas Checks is a tangible example of how I work: technical delivery combined with an understanding of the whole process. From the first bottleneck to the eventual follow-up, the solution needs to fit together.
I develop custom web applications, internal tools, client portals and automation. When your project needs additional logic, a better interface or an integration, I plan and build the relevant components.
What matters is not what could theoretically be built, but what genuinely helps your business. We discuss scope, priorities and sensible next steps personally.
FROM YOUR IDEA TO THE RIGHT SOLUTION
You do not need a finished specification. A concrete task, bottleneck or idea is enough to start the conversation.
We discuss your objectives, existing systems and the way work actually gets done.
We identify the improvement with the strongest benefit and the right technology to support it.
The application, its workflows and clear tests are developed against an agreed scope.
Feedback and new requirements are translated into purposeful improvements and extensions.
CLARITY BEFORE THE FIRST CONVERSATION
Key questions about the system and working together.
Yes. Lukas Checks is an example of custom-built software. In an introductory call, we clarify your requirements and assess whether a dedicated application, an integration or better use of existing tools is the most useful approach.
No. The product images are localised feature illustrations with synthetic sample data. Internal domain lists, results and credentials remain in the protected admin area. Visiting this presentation does not start a monitoring check.
Once the hourly plan is configured, each active website and subdomain is checked for public HTTPS availability. TLS validation, the response and configured redirects are included. Additional content rules are optional. Actual execution depends on the webcron and available hosting capacity.
No. The system records the certificate being served, compares validity periods and prompts follow-up checks. Renewal is handled by the relevant provider or certificate management setup. A new certificate alone does not reveal whether the replacement happened automatically or manually.
An open personal task is completed by a suitable successful check that you explicitly request. If the same valid certificate is still being served, only the current warning stage is complete. A later stage may trigger another reminder. Visiting a page or relying only on an automatic check is not enough.
Suitable PHP hosting, a regularly invoked webcron and a configured notification channel. Direct origin checks need a confirmed origin configuration. An independent external watchdog is provided for a complete monitor outage. Notification routes must be tested on the actual hosting.
No. Brief outages between measurements can go unnoticed. A successful HTTPS request also does not prove that every function behind a login works. Additional requirements must be planned explicitly and implemented with appropriate testing methods.
The booking buttons lead to my appointment page on lukasteissl.com. In a personal, no-obligation introductory call, we discuss your situation and the most useful next step. You do not need a completed technical design.
YOUR NEXT SYSTEM
Bring your idea, bottleneck or recurring task. We will discuss a solution that fits — thoughtfully designed, individually developed and focused on practical value.
Book a call with Lukas Teissl Personal · no obligation · no finished specification needed